From 63de9b8b05b4c1951b68d27df789f80ef2901b36 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:10:18 +0000 Subject: [PATCH 1/2] i18n(uk): translation import part 05 of 13 (23 files) --- .../docs/nodes-and-clients/bootnodes/index.md | 31 ++ .../client-diversity/index.md | 132 +++++ .../docs/nodes-and-clients/index.md | 319 ++++++++++++ .../nodes-and-clients/light-clients/index.md | 61 +++ .../node-architecture/index.md | 59 +++ .../nodes-as-a-service/index.md | 418 +++++++++++++++ .../nodes-and-clients/run-a-node/index.md | 484 ++++++++++++++++++ .../uk/developers/docs/oracles/index.md | 433 ++++++++++++++++ .../docs/programming-languages/dart/index.md | 32 ++ .../programming-languages/delphi/index.md | 56 ++ .../programming-languages/dot-net/index.md | 86 ++++ .../programming-languages/elixir/index.md | 55 ++ .../programming-languages/golang/index.md | 84 +++ .../docs/programming-languages/index.md | 32 ++ .../docs/programming-languages/java/index.md | 64 +++ .../programming-languages/javascript/index.md | 72 +++ .../programming-languages/python/index.md | 99 ++++ .../docs/programming-languages/ruby/index.md | 60 +++ .../docs/programming-languages/rust/index.md | 65 +++ .../uk/developers/docs/scaling/index.md | 113 ++++ .../docs/scaling/optimistic-rollups/index.md | 265 ++++++++++ .../developers/docs/scaling/plasma/index.md | 176 +++++++ .../docs/scaling/sidechains/index.md | 73 +++ 23 files changed, 3269 insertions(+) create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/bootnodes/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/client-diversity/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/light-clients/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/node-architecture/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/nodes-as-a-service/index.md create mode 100644 public/content/translations/uk/developers/docs/nodes-and-clients/run-a-node/index.md create mode 100644 public/content/translations/uk/developers/docs/oracles/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/dart/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/delphi/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/dot-net/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/elixir/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/golang/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/java/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/javascript/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/python/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/ruby/index.md create mode 100644 public/content/translations/uk/developers/docs/programming-languages/rust/index.md create mode 100644 public/content/translations/uk/developers/docs/scaling/index.md create mode 100644 public/content/translations/uk/developers/docs/scaling/optimistic-rollups/index.md create mode 100644 public/content/translations/uk/developers/docs/scaling/plasma/index.md create mode 100644 public/content/translations/uk/developers/docs/scaling/sidechains/index.md diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..97b3d32c6bf --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: "Вступ до завантажувальних вузлів Ethereum" +description: "Основна інформація, необхідна для розуміння завантажувальних вузлів" +lang: uk +--- + +Коли новий вузол приєднується до мережі Ethereum, йому необхідно з'єднатися з вузлами, які вже є в мережі, щоб потім знайти нових однорангових партнерів. Ці точки входу в мережу Ethereum називаються завантажувальними вузлами. Зазвичай клієнти мають список завантажувальних вузлів, який жорстко закодовано у них. Ці завантажувальні вузли зазвичай запускаються командою розробників Ethereum Foundation або самими клієнтськими командами. Зверніть увагу, що завантажувальні вузли - це не те саме, що статичні вузли. Статичні вузли викликаються знову і знову, в той час, як завантажувальні вузли викликаються лише тоді, коли не вистачає однорангових вузлів для з'єднання, і вузлу потрібно завантажити нові з'єднання. + +## Підключення до завантажувального вузла {#connect-to-a-bootnode} + +Більшість клієнтів мають вбудований список завантажувальних вузлів, але ви також можете захотіти запустити власний завантажувальний вузол або використати той, який не є частиною жорстко закодованого списку клієнта. У цьому випадку ви можете вказати їх під час запуску вашого клієнта, як показано нижче (приклад для Geth, будь ласка, перевірте документацію вашого клієнта): + +``` +geth --bootnodes "enode://@:" +``` + +## Запуск завантажувального вузла {#run-a-bootnode} + +Завантажувальні вузли — це повні вузли, що не знаходяться за NAT ([трансляція мережевих адрес](https://www.geeksforgeeks.org/network-address-translation-nat/)). Кожен повний вузол може діяти як завантажувальний вузол за умови, що він є загальнодоступним. + +Під час запуску вузла він має зареєструвати ваш [enode](/developers/docs/networking-layer/network-addresses/#enode), що є публічним ідентифікатором, який інші можуть використовувати для підключення до вашого вузла. + +Enode зазвичай повторно генерується під час кожного перезапуску, тому обов’язково перегляньте документацію вашого клієнта про те, як згенерувати постійний enode для вашого завантажувального вузла. + +Щоб бути хорошим завантажувальним вузлом, варто збільшити максимальну кількість пірів, які можуть до нього підключитися. Запуск завантажувального вузла з багатьма пірами значно збільшить вимоги до пропускної здатності. + +## Доступні завантажувальні вузли {#available-bootnodes} + +Список вбудованих завантажувальних вузлів у go-ethereum можна знайти [тут](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Ці завантажувальні вузли підтримуються Ethereum Foundation та командою go-ethereum. + +Існують також інші списки завантажувальних вузлів, які підтримуються волонтерами. Будь ласка, переконайтеся, що ви завжди включаєте принаймні один офіційний завантажувальний вузол, інакше ви можете зазнати атаки затемнення. diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..467ca07ae04 --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,132 @@ +--- +title: "Різноманіття клієнтів" +description: "Високорівневе пояснення важливості різноманітності клієнтів Ethereum." +lang: uk +sidebarDepth: 2 +--- + +Поведінка вузла Ethereum контролюється клієнтським програмним забезпеченням, яке він запускає. Існує кілька клієнтів Ethereum виробничого рівня, кожен з яких розробляється і підтримується різними мовами окремими командами. Клієнти створені за єдиною специфікацією, що забезпечує безперебійну взаємодію клієнтів між собою, однакову функціональність та еквівалентний користувацький досвід. Однак, на даний момент розподіл клієнтів між вузлами недостатньо рівномірний, щоб реалізувати це зміцнення мережі в повній мірі. В ідеалі, користувачі розподіляються приблизно порівну між різними клієнтами, щоб забезпечити якомога більшу різноманітність клієнтів у мережі. + +## Передумови {#prerequisites} + +Якщо ви ще не знаєте, що таке вузли та клієнти, перегляньте статтю [вузли та клієнти](/developers/docs/nodes-and-clients/). Визначення [рівня виконання](/glossary/#execution-layer) та [рівня консенсусу](/glossary/#consensus-layer) можна знайти в глосарії. + +## Чому існують множинні клієнти? {#why-multiple-clients} + +Існує багато незалежних клієнтів, які розробляються і підтримуються, тому що різноманітність клієнтів робить мережу більш стійкою до атак і помилок. Множинні клієнти - це унікальна перевага Ethereum - інші блокчейни покладаються на непогрішність одного клієнта. Однак недостатньо просто мати кілька доступних клієнтів, їх має прийняти спільнота, а загальна кількість активних вузлів має бути розподілена між ними відносно рівномірно. + +## Чому різноманітність клієнтів важлива? {#client-diversity-importance} + +Наявність великої кількості клієнтів, які самостійно розвиваються та підтримуються, є життєво важливою для працездатності децентралізованої мережі. Розберімося, чому це так. + +### Помилки {#bugs} + +Помилка в окремому клієнті становить менший ризик для мережі, коли він представляє меншість вузлів Ethereum. При приблизно рівномірному розподілі вузлів між багатьма клієнтами, ймовірність того, що більшість клієнтів постраждають від спільної проблеми, невелика, і, як наслідок, мережа є більш надійною. + +### Стійкість до атак {#resilience} + +Різноманітність клієнтів також забезпечує стійкість до атак. Наприклад, атака, що [обманом заманює певного клієнта](https://twitter.com/vdWijden/status/1437712249926393858) в певну гілку ланцюжка, навряд чи буде успішною, оскільки інші клієнти навряд чи будуть вразливими таким же чином, а канонічний ланцюжок залишиться неушкодженим. Низька різноманітність клієнтів збільшує ризик, пов'язаний зі зломом домінуючого клієнта. Різноманітність клієнтів вже виявилася важливим захистом від зловмисних атак на мережу, наприклад, Шанхайська атака на відмову в обслуговуванні в 2016 році стала можливою завдяки тому, що зловмисники змогли обдурити домінуючий клієнт (Geth), змусивши його виконувати операції вводу-виводу на повільному диску десятки тисяч разів за блок. Оскільки в мережі також були альтернативні клієнти, які не мали вразливості, Ethereum зміг протистояти атаці і продовжити роботу, поки вразливість в Geth не була виправлена. + +### Завершеність proof-of-stake {#finality} + +Помилка в консенсусі, що охоплює понад 33% вузлів Ethereum, може перешкодити завершенню роботи над рівнем консенсусу, а це означає, що користувачі не можуть бути впевнені в тому, що транзакції не будуть скасовані або змінені в якийсь момент. Це може бути проблематично для багатьох додатків, побудованих на основі Ethereum, особливо для DeFi. + + Гірше того, критична помилка в клієнті, що має більшість у дві третини, може призвести до того, що ланцюжок неправильно розділиться та фіналізується, що призведе до того, що великий набір валідаторів застрягне в недійсному ланцюжку. Якщо вони захочуть знову приєднатися до правильного ланцюжка, ці валідатори зіткнуться з відсіканням або повільним і дорогим добровільним виходом і повторною активацією. Масштаб викреслювання залежить від кількості винних вузлів, більшість яких була викреслена на дві третини (32 ETH). + +Хоча це малоймовірні сценарії, екосистема Ethereum може зменшити їх ризик, вирівнюючи розподіл клієнтів між активними вузлами. В ідеалі, жоден консенсусний клієнт ніколи не досяг би частки 33% від загальної кількості вузлів. + +### Спільна відповідальність {#responsibility} + +Наявність мажоритарних клієнтів також пов'язана з людськими втратами. Це покладає надмірне навантаження та відповідальність на невелику команду розробників. Чим менша різноманітність клієнтів, тим більший тягар відповідальності покладається на розробників, які обслуговують мажоритарних клієнтів. Розподіл цієї відповідальності між кількома командами корисний як для працездатності мережі вузлів Ethereum, так і для мережі людей. + +## Поточна різноманітність клієнтів {#current-client-diversity} + +### Клієнти виконання {#execution-clients-breakdown} + + + +### Клієнти консенсусу {#consensus-clients-breakdown} + + + +Ця діаграма може бути застарілою — перейдіть на [ethernodes.org](https://ethernodes.org) та [clientdiversity.org](https://clientdiversity.org) для отримання актуальної інформації. + +Дві кругові діаграми вище показують знімки поточної різноманітності клієнтів для рівнів виконання та консенсусу (на момент написання в жовтні 2025 року). Різноманітність клієнтів з роками покращилася, і на рівні виконання спостерігається зменшення домінування [Geth](https://geth.ethereum.org/), [Nethermind](https://www.nethermind.io/nethermind-client) посідає друге місце, [Besu](https://besu.hyperledger.org/) — третє, а [Erigon](https://github.com/ledgerwatch/erigon) — четверте, при цьому інші клієнти становлять менше 3% мережі. Найчастіше використовуваний клієнт на рівні консенсусу — [Lighthouse](https://lighthouse.sigmaprime.io/) — має показники, близькі до другого за популярністю клієнта. На [Prysm](https://prysmaticlabs.com/#projects) та [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) припадає ~31% і ~14% відповідно, а інші клієнти використовуються рідко. + +Дані рівня виконання були отримані з [supermajority.info](https://supermajority.info/) 26 жовтня 2025 року. Дані для клієнтів консенсусу були отримані від [Michael Sproul](https://github.com/sigp/blockprint). Дані про клієнтів рівня консенсусу отримати складніше, оскільки клієнти рівня консенсусу не завжди мають однозначні сліди, які можна використати для їхньої ідентифікації. Дані були згенеровані за допомогою алгоритму класифікації, який іноді плутає деяких клієнтів меншості (докладніше дивіться [тут](https://twitter.com/sproulM_/status/1440512518242197516)). На діаграмі вище ці неоднозначні класифікації обробляються з позначкою «або/або» (наприклад, Nimbus/Teku). Тим не менш, очевидно, що більша частина мережі використовує Prysm. Попри те, що це лише знімки, значення на діаграмі дають гарне загальне уявлення про поточний стан клієнтського розмаїття. + +Актуальні дані про різноманітність клієнтів для рівня консенсусу тепер доступні на [clientdiversity.org](https://clientdiversity.org/). + +## Рівень виконання {#execution-layer} + +Досі розмова про клієнтське розмаїття зосереджувалася переважно на рівні консенсусу. Однак на клієнт виконання [Geth](https://geth.ethereum.org) наразі припадає близько 85% усіх вузлів. Цей відсоток є проблематичним з тих же причин, що і для консенсусних клієнтів. Наприклад, помилка в Geth, що впливає на обробку транзакцій або побудову корисного навантаження виконання, може призвести до того, що консенсусні клієнти завершуватимуть проблемні або пошкоджені транзакції. Тому Ethereum був би працездатнішим при більш рівномірному розподілі клієнтів виконання, в ідеалі, коли жоден клієнт не представляв би понад 33% мережі. + +## Використовуйте клієнт меншості {#use-minority-client} + +Вирішення проблеми різноманітності клієнтів вимагає не лише від окремих користувачів вибору клієнтів меншості — це також вимагає, щоб пули валідаторів та установи, як-от великі dapp і біржі, теж переходили на інші клієнти. Однак, всі користувачі можуть робити свою роль у поєднанні поточного дисбалансу, нормалізуючи використання доступного програмного забезпечення для Ethereum. Після злиття всі оператори вузлів повинні будуть запустити клієнта виконання і клієнта консенсусу. Вибір комбінацій клієнтів, запропонованих нижче, допоможе збільшити різноманітність клієнтів. + +### Клієнти виконання {#execution-clients} + +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) + +### Клієнти консенсусу {#consensus-clients} + +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) + +Технічні користувачі можуть допомогти прискорити цей процес, написавши більше навчальних посібників і документації для міноритарних клієнтів і заохочуючи своїх колег, які працюють на вузлах, мігрувати від домінуючих клієнтів. Посібники з переходу на клієнт консенсусу меншості доступні на [clientdiversity.org](https://clientdiversity.org/). + +## Панелі моніторингу різноманітності клієнтів {#client-diversity-dashboards} + +Кілька інформаційних панелей в режимі реального часу надають статистику різноманітності клієнтів для рівня виконання та консенсусу. + +**Консенсусний шар:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) + +**Рівень виконання:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## Для подальшого читання {#further-reading} + +- [Різноманітність клієнтів на рівні консенсусу Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [Злиття Ethereum: запускайте клієнт більшості на свій страх і ризик!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) — _Данкрад Фіст, 24 березня 2022 р._ +- [Важливість різноманітності клієнтів](https://our.status.im/the-importance-of-client-diversity/) +- [Список сервісів вузлів Ethereum](https://ethereumnodes.com/) +- [«П’ять чому» проблеми різноманітності клієнтів](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [Різноманітність Ethereum і як її вирішити (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## Пов'язані теми {#related-topics} + +- [Запустіть вузол Ethereum](/run-a-node/) +- [Вузли та клієнти](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/index.md new file mode 100644 index 00000000000..bed2e58f1d0 --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/index.md @@ -0,0 +1,319 @@ +--- +title: "Мережеві вузли та користувачі" +description: "Огляд вузлів Ethereum і програмного забезпечення клієнтів, а також налаштування вузлів і чому ви повинні це зробити." +lang: uk +sidebarDepth: 2 +--- + +Ethereum - це розподілена мережа комп'ютерів (відомих як вузли), на яких працює програмне забезпечення, що може перевіряти блоки і дані транзакцій. Для перетворення вашого комп'ютера в вузол Ethereum необхідно запустити відповідне програмне забезпечення на ньому. Для створення вузла необхідно використовувати два окремі компоненти програмного забезпечення (відомі як "клієнти"). + +## Передумови {#prerequisites} + +Вам слід розуміти концепцію однорангової мережі та [основи EVM](/developers/docs/evm/), перш ніж заглиблюватися і запускати власний екземпляр клієнта Ethereum. Перегляньте наш [вступ до Ethereum](/developers/docs/intro-to-ethereum/). + +Якщо ви не знайомі з темою вузлів, радимо спочатку ознайомитися з нашим простим посібником про [запуск вузла Ethereum](/run-a-node). + +## Що таке вузли та клієнти? Чи впливає це оновлення на всі вузли та валідаторів Ethereum? {#what-are-nodes-and-clients} + +"Вузол" - це будь-який екземпляр клієнтського програмного забезпечення Ethereum, який з'єднаний з іншими комп'ютерами, на яких також працює програмне забезпечення Ethereum, утворюючи мережу. Клієнт - це реалізація Ethereum, яка перевіряє дані на відповідність правилам протоколу і забезпечує безпеку мережі. Вузол повинен запускати два клієнти: клієнт консенсусу та виконавчий клієнт. + +- Клієнт виконавець (також відомий як Execution Engine, клієнт EL або раніше Eth1-клієнт) прослуховує нові транзакції, що транслюються в мережі, виконує їх в EVM, а також зберігає останній стан і базу даних всіх поточних даних Ethereum. +- Клієнт консенсусу (також відомий як Beacon Node, клієнт CL або раніше Eth2-клієнт) реалізує алгоритм консенсусу з доказом частки, який дозволяє мережі досягти згоди на основі перевірених даних від клієнта виконавця. Також існує третій компонент програмного забезпечення, відомий як "валідатор", який може бути доданий до клієнта консенсусу, що дозволяє вузлу приймати участь у забезпеченні безпеки мережі. + +Ці клієнти спільно працюють для відстеження головного блоку ланцюжка Ethereum та надають можливість користувачам взаємодіяти з мережею Ethereum. Модульна конструкція, в якій декілька програмних компонентів працюють разом, називається [інкапсульованою складністю](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Такий підхід спростив безперебійне виконання [The Merge](/roadmap/merge), полегшує обслуговування та розробку клієнтського програмного забезпечення, а також дає змогу повторно використовувати окремі клієнти, наприклад, в [екосистемі рівня 2](/layer-2/). + +![Схема зв’язаних клієнтів виконання та консенсусу](./eth1eth2client.png) +Спрощена схема зв’язаних клієнтів виконання та консенсусу. + +### Різноманітність клієнтів {#client-diversity} + +Існують [клієнти виконання](/developers/docs/nodes-and-clients/#execution-clients) та [клієнти консенсусу](/developers/docs/nodes-and-clients/#consensus-clients), написані різними мовами програмування та розроблені різними командами. + +Кілька клієнтських впроваджень можуть зробити мережу сильнішою, зменшуючи її залежність від однієї кодової бази. Ідеальна мета полягає в тому, щоб досягти різноманітності без домінування жодного клієнта в мережі, тим самим уникаючи потенційної єдиної точки відмови. +Різноманітність мов також залучає ширшу спільноту розробників і дозволяє їм створювати інтеграції їхньою улюбленою мовою. + +Дізнайтеся більше про [різноманітність клієнтів](/developers/docs/nodes-and-clients/client-diversity/). + +Спільним для цих впроваджень є те, що всі вони відповідають єдиній специфікації. Специфікації визначають, як функціонує мережа Ethereum і блокчейн. Кожна технічна деталь визначена, а специфікації можна переглянути за посиланнями: + +- Спочатку [Жовта книга Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Специфікації виконання](https://github.com/ethereum/execution-specs/) +- [Специфікації консенсусу](https://github.com/ethereum/consensus-specs) +- [EIP](https://eips.ethereum.org/), реалізовані в різних [оновленнях мережі](/ethereum-forks/) + +### Відстеження вузлів у мережі {#network-overview} + +Кілька трекерів пропонують перегляд вузлів мережі Ethereum в реальному часі. Зауважте, що через природу децентралізованих мереж ці сканери можуть надавати лише обмежений огляд мережі і можуть показувати різні результати. + +- [Карта вузлів](https://etherscan.io/nodetracker) від Etherscan +- [Ethernodes](https://ethernodes.org/) від Bitfly +- [Nodewatch](https://www.nodewatch.io/) від Chainsafe, сканування вузлів консенсусу +- [Monitoreth](https://monitoreth.io/) від MigaLabs, розподілений інструмент для моніторингу мережі +- [Щотижневі звіти про стан мережі](https://probelab.io) від ProbeLab, з використанням [сканера Nebula](https://github.com/dennis-tra/nebula) та інших інструментів + +## Типи вузлів {#node-types} + +Якщо ви хочете [запустити власний вузол](/developers/docs/nodes-and-clients/run-a-node/), ви повинні розуміти, що існують різні типи вузлів, які споживають дані по-різному. Фактично, клієнти можуть запускати три різні типи вузлів: легкі, повні та архівні. Існують також варіанти різних стратегій синхронізації, які дозволяють пришвидшити час синхронізації. Синхронізація означає, наскільки швидко можна отримати найсвіжішу інформацію про стан Ethereum. + +### Повний вузол {#full-node} + +Повні вузли виконують блок-по-блоку перевірку блокчейну, включаючи завантаження та перевірку тіла блоку та даних стану для кожного блоку. Існують різні класи повних вузлів: деякі починають із генезис-блоку та перевіряють кожен блок в усій історії блокчейну. Інші починають перевірку з новішого блоку, який вони вважають дійсним (наприклад, «snap sync» від Geth). Незалежно від того, звідки починається перевірка, повні вузли зберігають лише локальну копію відносно нових даних (зазвичай останні 128 блоків), що дозволяє видаляти старіші дані для економії місця на диску. Старі дані можуть бути відновлені, коли вони потрібні. + +- Зберігає повні дані блокчейну (хоча вони періодично обрізаються, тому повний вузол не зберігає всі дані про стан аж до генезису) +- Бере участь у валідації, перевіряє всі блоки та стани. +- Всі стани можуть бути отримані або відновлені з локального сховища або зі снапшотів повним вузлом. +- Обслуговує мережу і надає дані за запитом. + +### Архівний вузол {#archive-node} + +Архівні вузли (Archive nodes) - це повні вузли, які перевіряють кожний блок від генезиса і ніколи не видаляють жодних завантажених даних. + +- Зберігає все, що знаходиться у повному вузлі та створює архів історичних станів. Він потрібен, якщо ви хочете запросити щось на кшталт балансу облікового запису в блоці № 4 000 000 або просто та надійно перевірити власний набір транзакцій, не перевіряючи їх за допомогою трасування. +- Ці дані представляють одиниці терабайт, що робить архівні вузли менш привабливими для звичайних користувачів, але може бути корисним для таких сервісів, як інструменти дослідження блоків, постачання гаманців і аналітика ланцюжків. + +Синхронізація клієнтів в будь-якому режимі, окрім архіву, призведе до видалення даних блокчейна. Це означає, що не існує архіву всіх історичних станів, але повний вузол здатен створювати їх на вимогу. + +Дізнайтеся більше про [архівні вузли](/developers/docs/nodes-and-clients/archive-nodes). + +### Легкий вузол {#light-node} + +Замість того, щоб завантажувати кожен блок, легкі вузли завантажують заголовки блоків. Ці заголовки містять лише загальну інформацію про вміст блоків. Будь-яка інша інформація, яка потрібна легкому вузлу, запитується у повного вузла. Після цього легкий вузол може самостійно звіряти отримані дані з кореневими станами в заголовках блоків. Легкі вузли дозволяють користувачам брати участь в мережі Ethereum без потужного обладнання або високої пропускної здатності, необхідних для роботи повних вузлів. Зрештою, легкі вузли можуть працювати на мобільних телефонах або вбудованих пристроях. Легкі вузли не беруть участі в консенсусі (тобто вони не можуть бути валідаторами), але вони можуть отримати доступ до блокчейну Ethereum з тією ж функціональністю та гарантіями безпеки, що й повний вузол. + +Легкі клієнти - це область активного розвитку Ethereum, і ми очікуємо, що незабаром з'являться нові легкі клієнти для рівня консенсусу і рівня виконання. +Існують також потенційні маршрути для надання даних легкого клієнта через [мережу пліток](https://www.ethportal.net/). Це вигідно, оскільки мережа пліток може підтримувати мережу легких вузлів, не потребуючи повних вузлів для обслуговування запитів. + +Ethereum поки що не підтримує велику кількість легких вузлів, але очікується, що підтримка легких вузлів буде швидко розвиватися в найближчому майбутньому. Зокрема, такі клієнти, як [Nimbus](https://nimbus.team/), [Helios](https://github.com/a16z/helios) та [LodeStar](https://lodestar.chainsafe.io/), наразі значною мірою зосереджені на легких вузлах. + +## Для чого запускати вузол Ethereum? Чи впливає це оновлення на всі вузли та валідаторів Ethereum? {#why-should-i-run-an-ethereum-node} + +Запуск вузла дозволяє вам безпосередньо, безперешкодно і приватно використовувати Ethereum, одночасно підтримуючи мережу, роблячи її більш надійною і децентралізованою. + +### Переваги для вас {#benefits-to-you} + +Запуск власного вузла забезпечує вам приватне, незалежне і надійне використання Ethereum. Вам не обов‘язково довіряти мережі, оскільки ви можете перевірити дані самостійно із своїм клієнтом. «Не довіряй, а провіряй» - популярна мантра блокчейну. + +- Ваш вузол перевіряє всі транзакції та блоки відповідно до правил консенсусу. Це означає, що ви не повиннні покладатися на інші вузли в мережі чи повністю довіряти їм. +- Ви можете використовувати гаманець Ethereum з власним вузлом. Ви можете використовувати децентралізовані додатки більш безпечно і конфіденційно, тому що вам не доведеться передавати свої адреси і баланси випадковим вузлам. Все можна перевірити за допомогою власного клієнта. [MetaMask](https://metamask.io), [Frame](https://frame.sh/) та [багато інших гаманців](/wallets/find-wallet/) пропонують імпорт RPC, що дозволяє їм використовувати ваш вузол. +- Ви можете запускати і самостійно розміщувати інші сервіси, які залежать від даних з Ethereum. Наприклад, це може бути валідатор ланцюжка Beacon Chain, програмне забезпечення другого шару, інфраструктура, дослідники блоків, платіжні процесори тощо. +- Ви можете надавати власні [кінцеві точки RPC](/developers/docs/apis/json-rpc/). Ви можете навіть публічно пропонувати ці точки доступу спільноті, щоб допомогти їм уникати великих централізованих постачальників. +- Ви можете підключатися до свого вузла за допомогою **міжпроцесної взаємодії (IPC)** або переписати вузол, щоб завантажити програму як плагін. Це забезпечує низьку затримку, що дуже допомагає, наприклад, при обробці великих обсягів даних за допомогою бібліотек web3, або коли вам потрібно замінити свої транзакції якомога швидше (тобто, фронтранінг). +- Ви можете безпосередньо вкладати ETH, щоб захистити мережу і отримувати винагороду. Щоб почати, див. розділ [соло-стейкінг](/staking/solo/). + +![Як ви отримуєте доступ до Ethereum через ваш додаток і вузли](./nodes.png) + +### Переваги для мережі {#network-benefits} + +Різноманітний набір вузлів важливий для працездатності Ethereum, безпеки та операційноі стійкості. + +- Повні вузли забезпечують дотримання правил консенсусу, тому їх неможливо обманом змусити прийняти блоки, які їм не відповідають. Це забезпечує додаткову безпеку в мережі, тому що якби всі вузли були легкими, які не виконують повну перевірку, валідатори могли б атакувати мережу. +- У разі атаки, яка долає криптоекономічний захист [proof-of-stake](/developers/docs/consensus-mechanisms/pos/#what-is-pos), соціальне відновлення може бути виконано повними вузлами, які обирають слідувати чесному ланцюжку. +- Більша кількість вузлів у мережі призводить до більш різноманітної та надійної мережі, що є кінцевою метою децентралізації, яка забезпечує стійкість до цензури та надійність системи. +- Повні вузли надають доступ до даних блокчейну для легковажних клієнтів, які на них покладаються. Легкі вузли не зберігають увесь блокчейн, натомість вони перевіряють дані за допомогою [коренів стану в заголовках блоків](/developers/docs/blocks/#block-anatomy). При необхідності вони можуть запитати додаткову інформацію у блоків. + +Якщо ви запускаєте повний вузол, то від цього користується весь мережа Ethereum, навіть якщо ви не запускаєте валідатора. + +## Запуск власного вузла {#running-your-own-node} + +Бажаєте запустити власного клієнта Ethereum? + +Щоб отримати просте для початківців введення та дізнатися більше, відвідайте нашу сторінку [Запуск вузла](/run-a-node). + +Якщо ви більш технічно підкований користувач, зануртеся в деталі та варіанти, як [розгорнути власний вузол](/developers/docs/nodes-and-clients/run-a-node/). + +## Альтернативи {#alternatives} + +Створення власного вузла може коштувати вам часу і ресурсів, але вам не завжди потрібно запускати власний екземпляр. У цьому випадку ви можете скористатися стороннім API-провайдером. Щоб отримати огляд використання цих послуг, перегляньте [вузли як послуга](/developers/docs/nodes-and-clients/nodes-as-a-service/). + +Якщо хтось запускає вузол Ethereum з загальнодоступним API у вашій спільноті, ви можете вказати свій гаманець до вузла спільноти за допомогою Custom RPC і отримати більше приватності, ніж з будь-якою випадковою довіреною третьою стороною. + +З іншого боку, якщо ви запускаєте клієнта, ви можете поділитися ним із друзями, яким він може знадобитися. + +## Клієнти виконання {#execution-clients} + +Спільнота Ethereum підтримує кілька клієнтів виконання з відкритим вихідним кодом (раніше відомих як «клієнти Eth1» або просто «клієнти Ethereum»), розроблених різними командами, що використовують різні мови програмування. Це робить мережу сильнішою та більш [різноманітною](/developers/docs/nodes-and-clients/client-diversity/). Ідеальна мета - досягти різноманітності без домінування клієнта, щоб зменшити кількість одиничних точок відмови. + +В цій таблиці узагальнено список різних клієнтів. Усі вони проходять [тести клієнтів](https://github.com/ethereum/tests) і активно підтримуються, щоб відповідати оновленням мережі. + +| Клієнт | Мова | Операційні системи | Мережі | Стратегії синхронізації | Відсікання станів | +| -------------------------------------------------------------------------------------------------- | ------------------------ | --------------------- | ----------------------- | ------------------------------------------------------------------------------------ | -------------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync), [Full](#full-sync) | Архівний, Відсічений | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync) (без обслуговування), Fast, [Full](#full-sync) | Архівний, Відсічений | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync), [Fast](#fast-sync), [Full](#full-sync) | Архівний, Відсічений | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Full](#full-sync) | Архівний, Відсічений | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Full](#full-sync) | Архівний, Відсічений | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(бета-версія)_ | TypeScript | Linux, Windows, macOS | Sepolia, Hoodi | [Full](#full-sync) | Скорочений | + +Щоб дізнатися більше про підтримувані мережі, читайте про [мережі Ethereum](/developers/docs/networks/). + +У кожного клієнта є унікальний варіант використання і переваги, тому виберіть одного залежно від своїх вподобань. Різноманітність дозволяє реалізації фокусуватися на різних функціях та користувацьких аудиторіях. Ви можете вибрати клієнта на основі функцій, підтримки, мови програмування або ліцензій. + +### Besu {#besu} + +Hyperledger Besu - це клієнт Ethereum корпоративного рівня як для загальнодоступних, так і для мереж із контрольованим доступом. Він підтримує всі функції Ethereum Mainnet, від трасування до GraphQL, має великий моніторинг і підтримується ConsenSys як у відкритих каналах спільноти, так і в рамках комерційних угод про рівень обслуговування для підприємств. Написаний на Java та має ліцензію Apache 2.0. + +Розширена [документація](https://besu.hyperledger.org/en/stable/) Besu допоможе вам розібратися з усіма деталями його функцій та налаштувань. + +### Erigon {#erigon} + +Erigon, раніше відомий як Turbo-Geth, починався як форк Go Ethereum, орієнтований на швидкість і ефективність використання дискового простору. Erigon - це повністю перепроєктована реалізація Ethereum, яка наразі написана на мові Go, але в процесі розробки знаходяться реалізації на інших мовах. Мета Erigon – забезпечити більш швидку, модульну та оптимізовану реалізацію Ethereum. Він може виконати повну синхронізацію архівних вузлів, використовуючи близько 2 Тб дискового простору, менш ніж за 3 дні. + +### Go Ethereum {#geth} + +Go Ethereum (скорочено - Geth) - це одна з оригінальних реалізацій протоколу Ethereum. Наразі, це найпоширеніший клієнт з найбільшою базою користувачів та різноманітністю інструментів для користувачів та розробників. Він написаний на Go, з повністю відкритим вихідним кодом та ліцензований згідно з GNU LGPL v3. + +Дізнайтеся більше про Geth в його [документації](https://geth.ethereum.org/docs/). + +### Nethermind {#nethermind} + +Nethermind - це реалізація Ethereum, створена за допомогою технологічного стеку C# .NET, ліцензована LGPL-3.0, що працює на всіх основних платформах, включаючи ARM. Пропонує відмінну продуктивність з: + +- оптимізованою віртуальною машиною +- доступом станів +- мережеві можливості та розширені функції, як-от інформаційні панелі Prometheus/Grafana, підтримка корпоративного журналування seq, трасування JSON-RPC та аналітичні плагіни. + +Nethermind також має [детальну документацію](https://docs.nethermind.io), потужну підтримку розробників, онлайн-спільноту та цілодобову підтримку для преміум-користувачів. + +### Reth {#reth} + +Reth (скорочення від Rust Ethereum) — це реалізація повного вузла Ethereum, яка орієнтована на зручність для користувача, високу модульність, швидкість та ефективність. Reth спочатку був створений і розвинений компанією Paradigm і ліцензований за ліцензіями Apache та MIT. + +Reth готовий до використання в робочому середовищі та підходить для використання в критично важливих середовищах, таких як стейкінг або сервіси з високою безвідмовністю. Добре працює у випадках використання, де потрібна висока продуктивність із великим запасом, наприклад, для RPC, MEV, індексації, симуляцій та P2P-діяльності. + +Дізнайтеся більше, переглянувши [Reth Book](https://reth.rs/), або [репозиторій Reth на GitHub](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth). + +### У розробці {#execution-in-development} + +Ці клієнти все ще перебувають на ранніх стадіях розробки, і їх поки не рекомендується використовувати в робочому середовищі. + +#### EthereumJS {#ethereumjs} + +Клієнт виконання EthereumJS (EthereumJS) написаний на TypeScript і складається з низки пакунків, що включають основні примітиви Ethereum, представлені класами Block, Transaction і Merkle-Patricia Trie, а також основні компоненти клієнта, включно з реалізацією віртуальної машини Ethereum (EVM), класу блокчейну та мережевого стека DevP2P. + +Дізнайтеся більше, прочитавши його [документацію](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) + +## Клієнти консенсусу {#consensus-clients} + +Існує кілька клієнтів консенсусу (раніше відомих як клієнти Eth2) для підтримки [оновлень консенсусу](/roadmap/beacon-chain/). Вони відповідають за всю логіку, пов'язану з консенсусом, включно з алгоритмом вибору форка, обробкою атестацій та керуванням винагородами та штрафами в системі [доказу частки володіння](/developers/docs/consensus-mechanisms/pos). + +| Клієнт | Мова | Операційні системи | Мережі | +| ------------------------------------------------------------- | ---------- | --------------------- | -------------------------------------------------- | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Hoodi, Pyrmont, Sepolia тощо | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia тощо | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia тощо | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Hoodi, Pyrmont, Sepolia тощо | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Hoodi, Sepolia тощо | +| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia тощо | + +### Lighthouse {#lighthouse} + +Lighthouse - це реалізація клієнта консенсусу, написана на мові програмування Rust та розповсюджена за ліцензією Apache-2.0. Цей проект підтримується компанією Sigma Prime і є стабільним та готовим до використання в продукції з моменту старту Beacon Chain. На нього покладаються різні підприємства, стейкінг-пули та індивідуальні користувачі. Цей проект має на меті бути безпечним, продуктивним і сумісним в широкому спектрі середовищ, від настільних ПК до складних автоматизованих розгортань. + +Документацію можна знайти в [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) + +### Lodestar {#lodestar} + +Lodestar - це реалізація клієнта консенсусу, готова до використання в продукції, написана мовою програмування Typescript та розповсюджується за ліцензією LGPL-3.0. Цей проект підтримується компанією ChainSafe Systems і є найновішим серед реалізацій клієнта консенсусу для індивідуальних стейкерів, розробників та дослідників. Lodestar складається з вузла Beacon і клієнта валідатора, які працюють за допомогою реалізацій протоколів Ethereum на мові програмування JavaScript. Lodestar спрямований на поліпшення користування Ethereum за допомогою легковажних клієнтів, розширення доступності для більшої кількості розробників та подальший внесок у різноманітність екосистеми. + +Більше інформації можна знайти на [вебсайті Lodestar](https://lodestar.chainsafe.io/) + +### Nimbus {#nimbus} + +Nimbus - це реалізація клієнта консенсусу, написана мовою програмування Nim і розповсюджується за ліцензією Apache-2.0. Це готовий до використання в продукції клієнт, який використовується індивідуальними стейкерами і стейкінг пулами. Nimbus розроблений з урахуванням ефективного використання ресурсів, що дозволяє легко запускати його на обмежених ресурсах пристроях та корпоративній інфраструктурі з однаковою легкістю, не по жертвуючи стабільністю або продуктивністю винагород. Менший обсяг ресурсів означає, що клієнт має більший резерв безпеки, коли мережа перебуває під навантаженням. + +Дізнайтеся більше в [документації Nimbus](https://nimbus.guide/) + +### Prysm {#prysm} + +Prysm — це повнофункціональний клієнт консенсусу з відкритим кодом, написаний на Go та ліцензований за ліцензією GPL-3.0. Він має додатковий вебінтерфейс і надає пріоритет зручності користувача, документації та можливості налаштування як для домашніх стейкерів, так і для інституційних користувачів. + +Щоб дізнатися більше, відвідайте [документацію Prysm](https://prysm.offchainlabs.com/docs/). + +### Teku {#teku} + +Teku — один із перших клієнтів генезису Beacon Chain. Поряд зі звичайними цілями (безпека, надійність, стабільність, зручність використання, продуктивність) Teku спеціально прагне повністю відповідати всім різноманітним стандартам клієнтів консенсусу. + +Teku пропонує дуже гнучкі варіанти розгортання. Вузол маяка та клієнт валідатора можуть працювати разом як єдиний процес, що надзвичайно зручно для соло-стейкерів, або ж вузли можуть працювати окремо для складних операцій зі стейкінгу. Крім того, Teku повністю сумісний із [Web3Signer](https://github.com/ConsenSys/web3signer/) для безпеки ключів підпису та захисту від слешингу. + +Teku написаний на Java і ліцензований за ліцензією Apache 2.0. Його розробляє команда Protocols у ConsenSys, яка також відповідає за Besu та Web3Signer. Дізнайтеся більше в [документації Teku](https://docs.teku.consensys.net/en/latest/). + +### Grandine {#grandine} + +Grandine — це реалізація клієнта консенсусу, написана на Rust та ліцензована за ліцензією GPL-3.0. Він підтримується командою Grandine Core Team і є швидким, високопродуктивним та легким. Він підходить для широкого кола стейкерів: від соло-стейкерів, що працюють на пристроях з низькими ресурсами, таких як Raspberry Pi, до великих інституційних стейкерів, що обслуговують десятки тисяч валідаторів. + +Документацію можна знайти в [Grandine Book](https://docs.grandine.io/) + +## Режими синхронізації {#sync-modes} + +Щоб відстежувати та перевіряти поточні дані в мережі, клієнт Ethereum повинен синхронізуватися з останнім станом мережі. Це робиться шляхом завантаження даних з вузлів, криптографічної перевірки їх цілісності та створення локальної бази даних блокчейнів. + +Режими синхронізації має різні підходи до цього процесу з різними компромісами. Клієнти також відрізняються в їх здійсненні алгоритмів синхронізації. Завжди звертайтеся до офіційної документації обраного клієнта для уточнення особливостей реалізації. + +### Режими синхронізації рівня виконання {#execution-layer-sync-modes} + +Рівень виконання може працювати в різних режимах для різних випадків використання: від повторного виконання глобального стану блокчейну до синхронізації лише з верхівкою ланцюга з довіреної контрольної точки. + +#### Повна синхронізація {#full-sync} + +Повна синхронізація завантажує всі блоки (включно із заголовками та тілами блоків) і поступово відтворює стан блокчейну, виконуючи кожен блок, починаючи з генезис-блоку. + +- Мінімізує довіру та забезпечує найвищу безпеку, перевіряючи кожну транзакцію. +- При збільшенні кількості транзакцій на обробку всіх транзакцій може піти від кількох днів до кількох тижнів. + +[Архівні вузли](#archive-node) виконують повну синхронізацію, щоб створити (і зберегти) повну історію змін стану, зроблених кожною транзакцією в кожному блоці. + +#### Швидка синхронізація {#fast-sync} + +Як і повна синхронізація, швидка синхронізація завантажує всі блоки (включно із заголовками, транзакціями та квитанціями). Однак замість повторної обробки історичних транзакцій швидка синхронізація покладається на квитанції, доки не досягне нещодавньої верхівки, після чого перемикається на імпорт та обробку блоків для забезпечення роботи повного вузла. + +- Стратегія швидкої синхронізації. +- Зменшує потребу в обробці на користь використання пропускної здатності. + +#### Snap-синхронізація {#snap-sync} + +Snap-синхронізація також перевіряє ланцюжок блок за блоком. Однак замість того, щоб починати з генезис-блоку, snap-синхронізація починається з новішої «довіреної» контрольної точки, яка, як відомо, є частиною справжнього блокчейну. Вузол зберігає періодичні контрольні точки, видаляючи дані, старші за певний вік. Ці знімки використовуються для відновлення даних стану за потреби, а не для їх постійного зберігання. + +- Найшвидша стратегія синхронізації, наразі стандартна в Ethereum Mainnet. +- Заощаджує використання диска та пропускну здатність мережі без шкоди для безпеки. + +[Детальніше про snap-синхронізацію](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). + +#### Легка синхронізація {#light-sync} + +Легкий користувацький режим завантажує всі заголовки блоків, дані блоків та перевіряє деякі рандомно. Синхронізується лише вершина ланцюжка від довіреної контрольної точки. + +- Отримує лише останній стан, покладаючись на розробників та механізм консенсусу. +- Клієнт готовий до використання з поточним станом мережі за кілька хвилин. + +**Примітка** Легка синхронізація ще не працює з Ethereum на основі доказу частки володіння — нові версії легкої синхронізації мають з'явитися незабаром! + +[Детальніше про легкі клієнти](/developers/docs/nodes-and-clients/light-clients/) + +### Режими синхронізації рівня консенсусу {#consensus-layer-sync-modes} + +#### Оптимістична синхронізація {#optimistic-sync} + +Оптимістична синхронізація — це стратегія синхронізації після злиття, розроблена для опціонального включення та зворотної сумісності, що дозволяє вузлам виконання синхронізуватися за допомогою встановлених методів. Механізм виконання може _оптимістично_ імпортувати блоки маяка без їх повної перевірки, знаходити останню верхівку, а потім починати синхронізацію ланцюга за допомогою вищезазначених методів. Потім, після того, як клієнт виконання наздожене мережу, він повідомить клієнту консенсусу про дійсність транзакцій у Beacon Chain. + +[Детальніше про оптимістичну синхронізацію](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### Синхронізація за контрольною точкою {#checkpoint-sync} + +Синхронізація за контрольною точкою, також відома як синхронізація за слабкою суб'єктивністю, створює кращий досвід для користувачів під час синхронізації вузла Beacon. Вона ґрунтується на припущеннях про [слабку суб'єктивність](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/), що дає змогу синхронізувати Beacon Chain із недавньої контрольної точки слабкої суб'єктивності замість генезис-блоку. Синхронізація за контрольною точкою значно прискорює початкову синхронізацію з подібними припущеннями довіри, як і синхронізація з [генезис-блоку](/glossary/#genesis-block). + +На практиці це означає, що ваш вузол підключається до віддаленого сервісу для завантаження нещодавніх фіналізованих станів і продовжує перевірку даних із цієї точки. Третя сторона, що надає дані, є довіреною і повинна обиратися ретельно. + +Детальніше про [синхронізацію за контрольною точкою](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) + +## Для подальшого читання {#further-reading} + +- [Ethereum 101 — частина 2 — Розуміння вузлів](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes, 13 лютого 2019 р._ +- [Запуск повних вузлів Ethereum: посібник для ледь мотивованих](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 7 листопада 2019 р._ + +## Пов'язані теми {#related-topics} + +- [Блоки](/developers/docs/blocks/) +- [Мережі](/developers/docs/networks/) + +## Пов'язані посібники {#related-tutorials} + +- [Перетворіть свій Raspberry Pi 4 на вузол валідатора, просто прошивши карту MicroSD — посібник зі встановлення](/developers/tutorials/run-node-raspberry-pi/) _— прошийте свій Raspberry Pi 4, підключіть кабель Ethernet, підключіть SSD-диск і увімкніть пристрій, щоб перетворити Raspberry Pi 4 на повний вузол Ethereum, що запускає рівень виконання (Mainnet) та/або рівень консенсусу (Beacon Chain/валідатор)._ diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..67e934f17d8 --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: "Легкі клієнти" +description: "Знайомство з легкими клієнтами Ethereum." +lang: uk +--- + +Запуск повного вузла — це найбільш надійний, приватний, децентралізований і стійкий до цензури спосіб взаємодії з Ethereum. З повним вузлом ви зберігаєте свою власну копію блокчейну, яку можете миттєво запитувати, і ви отримуєте прямий доступ до однорангової мережі Ethereum. Однак для роботи повного вузла потрібен значний обсяг пам’яті, сховища та ЦП. Це означає, що не кожен може запустити свій власний вузол. У дорожній карті Ethereum є кілька рішень для цього, включно з безгромадянством, але до їх впровадження залишилося кілька років. Відповідь у найближчій перспективі полягає в тому, щоб змінити деякі переваги роботи повного вузла на значні покращення продуктивності, які дозволять вузлам працювати з значно нижчими вимогами до обладнання. Вузли, які роблять цей компроміс, відомі як легкі вузли. + +## Що таке легкий клієнт {#what-is-a-light-client} + +Легкий вузол — це вузол, на якому працює програмне забезпечення легкого клієнта. Замість того, щоб зберігати локальні копії даних блокчейну та самостійно перевіряти всі зміни, вони запитують необхідні дані у якогось постачальника. Постачальник може бути прямим підключенням до повного вузла або через якийсь централізований сервер RPC. Потім дані перевіряються легким вузлом, що дозволяє йому не відставати від блоку ланцюга. Світловий вузол обробляє лише заголовки блоків, іноді завантажуючи фактичний вміст блоку. Вузли можуть відрізнятися за своєю легкістю, залежно від комбінації легкого та повного клієнтського програмного забезпечення, яке вони виконують. Наприклад, найпростішою конфігурацією буде запуск клієнта легкого виконання та клієнта легкого консенсусу. Також імовірно, що багато вузлів вирішать запускати клієнтів легкого консенсусу з клієнтами повного виконання, або навпаки. + +## Як працюють легкі клієнти? {#how-do-light-clients-work} + +Коли Ethereum почав використовувати механізм консенсусу на основі proof-of-stake, була введена нова інфраструктура спеціально для підтримки легких клієнтів. Це працює шляхом випадкового вибору підмножини з 512 валідаторів кожні 1,1 дня, які діють як **синхронізаційний комітет**. Синхронізаційний комітет підписує заголовок останніх блоків. Кожен заголовок блоку містить сукупний підпис валідаторів у синхронізаційному комітеті та "бітове поле", що показує, які валідатори підписали, а які ні. Кожен заголовок також містить список валідаторів, які, як очікується, візьмуть участь у підписанні наступного блоку. Це означає, що легкий клієнт може швидко побачити, що синхронізаційний комітет підтвердив отримані дані, і вони також можуть перевірити, чи синхронізаційний комітет є справжнім, порівнюючи отриманий з тим, який їм було сказано очікувати в попередньому блоці. Таким чином легкий клієнт може постійно оновлювати свої знання про останній блок Ethereum, фактично не завантажуючи сам блок, лише заголовок, який містить підсумкову інформацію. + +На рівні виконання немає єдиної специфікації для клієнта легкого виконання. Обсяг клієнта легкого виконання може варіюватися від «легкого режиму» клієнта повного виконання, який має всі EVM і мережеві функції повного вузла, але лише перевіряє заголовки блоків без завантаження пов’язаних даних, або це може бути більше спрощений клієнт, який значною мірою покладається на пересилання запитів до постачальника RPC для взаємодії з Ethereum. + +## Чому легкі клієнти важливі? {#why-are-light-clients-important} + +Легкі клієнти мають значення, оскільки вони дозволяють користувачам перевіряти вхідні дані, а не сліпо довіряти тому, що їхній постачальник даних є коректним і чесним, використовуючи лише крихітну частку обчислювальних ресурсів повного вузла. Отримані клієнтами легкі дані можна перевірити за заголовками блоків, які, як вони знають, підписані принаймні 2/3 випадкового набору 512 валідаторів Ethereum. Це дуже переконливий доказ того, що дані є правильними. + +Легкий клієнт використовує лише невелику кількість обчислювальної потужності, пам’яті та сховища, тому його можна запускати на мобільному телефоні, вбудованому в додаток або як частину браузера. Легкі клієнти — це спосіб зробити доступ до Ethereum з мінімізованою довірою таким же безпроблемним, як і довіра сторонньому постачальнику. + +Розглянемо на простому прикладі. Уявіть, що ви хочете перевірити баланс свого рахунку. Для цього вам потрібно зробити запит до вузла Ethereum. Цей вузол перевірить локальну копію стану Ethereum на ваш баланс і поверне його вам. Якщо у вас немає прямого доступу до вузла, існують централізовані оператори, які надають ці дані як послугу. Ви можете надіслати їм запит, вони перевірять свій вузол і надішлють вам результат. Проблема полягає в тому, що вам доведеться довіряти постачальнику, який надасть вам правильну інформацію. Ви ніколи не зможете точно знати, що інформація правильна, якщо ви не можете перевірити її самостійно. + +Легкий клієнт розв'язує цю проблему. Ви все ще запитуєте дані від якогось зовнішнього постачальника, проте коли ви отримуєте дані назад, вони приходять із доказом того, що ваш легкий вузол може перевірити інформацію, яку він отримав у заголовку блоку. Це означає, що Ethereum перевіряє правильність ваших даних замість якогось надійного оператора. + +## Які інновації пропонують легкі клієнти? Які інновації уможливлюють легкі клієнти? {#what-innovations-do-light-clients-enable} + +Основна перевага легких клієнтів полягає в тому, що вони дозволяють більшій кількості людей отримувати доступ до Ethereum самостійно з незначними вимогами до обладнання та мінімальною залежністю від третіх сторін. Це добре для користувачів, оскільки вони можуть перевіряти власні дані, і це добре для мережі, оскільки збільшується кількість та різноманітність вузлів, які перевіряють ланцюжок. + +Можливість запускати вузли Ethereum на пристроях з невеликою пам’яттю, сховищем та обчислювальною потужністю є однією з головних областей інновацій, відкритих легкими клієнтами. У той час як сьогодні вузли Ethereum вимагають багато обчислювальних ресурсів, легкі клієнти можна вбудовувати в браузери, запускати на мобільних телефонах і, можливо, навіть на менших пристроях, таких як смартгодинник. Це означає, що гаманці Ethereum із вбудованими клієнтами можуть працювати на мобільному телефоні. Також те, що мобільні гаманці можуть бути набагато децентралізованішими, оскільки їм не доведеться довіряти свої дані централізованим постачальникам даних. + +Розширенням цього є забезпечення роботи пристроїв **інтернету речей (IoT)**. Легкий клієнт можна використовувати для швидкого підтвердження права власності на певний баланс токенів або NFT з усіма гарантіями безпеки, які надають комітети синхронізації, ініціюючи певні дії в мережі IoT. Уявіть собі [службу прокату велосипедів](https://youtu.be/ZHNrAXf3RDE?t=929), яка використовує застосунок із вбудованим легким клієнтом для швидкої перевірки, що ви є власником NFT цієї служби прокату, і якщо так, розблоковує для вас велосипед, на якому ви можете поїхати! + +Зведені програми Ethereum також виграють від легких клієнтів. Однією з великих проблем для зведень були хакерські атаки, націлені на мости, які дозволяють переказувати кошти з основної мережі Ethereum до зведення. Однією з вразливостей є оракули, які зведені дані використовують для виявлення того, що користувач вніс депозит у міст. Якщо оракул передає неправильні дані, вони можуть змусити зведення подумати, що депозит прибув на міст, і помилково випустити кошти. Легкий клієнт, вбудований у зведення, можна використовувати для захисту від пошкоджених оракулів, оскільки депозит у міст може надходити з доказом, який може бути перевірено зведенням перед випуском будь-яких токенів. Таку ж концепцію можна також застосувати до інших міжланцюгових мостів. + +Легкі клієнти також можна використовувати для оновлення гаманців Ethereum. Замість того, щоб довіряти даним, наданим постачальником RPC, ваш гаманець може безпосередньо перевіряти дані, які вам надаються, за допомогою вбудованого легкого клієнта. Це додасть безпеки вашому гаманцю. Якщо ваш постачальник RPC був нечесним і надав вам неправильні дані, вбудований легкий клієнт міг би вам сказати! + +## Який поточний стан розробки легких клієнтів? Поточний стан розробки {#current-state-of-development} + +У розробці є кілька легких клієнтів, включаючи виконання, консенсус та комбіновані клієнти виконання/консенсусу легких клієнтів. На момент написання цієї сторінки ми знаємо про такі легкі клієнтські реалізації: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): легкий клієнт консенсусу на TypeScript +- [Helios](https://github.com/a16z/helios): комбінований легкий клієнт виконання та консенсусу на Rust +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): легкий режим для клієнта виконання (у розробці) на Go +- [Nimbus](https://nimbus.guide/el-light-client.html): легкий клієнт консенсусу на Nim + +Наскільки нам відомо, жодна з них ще не вважається готовою до виробництва. + +Крім того, виконується велика кількість роботи для покращення способів доступу легких клієнтів до даних Ethereum. Наразі легкі клієнти покладаються на RPC-запити до повних вузлів, використовуючи модель «клієнт-сервер», але в майбутньому дані можна буде запитувати більш децентралізовано за допомогою виділеної мережі, як-от [Portal Network](https://www.ethportal.net/), яка зможе передавати дані легким клієнтам за допомогою пірингового протоколу поширення. + +Інші елементи [плану розвитку](/roadmap/), як-от [дерева Веркла](/roadmap/verkle-trees/) та [відсутність стану](/roadmap/statelessness/), згодом зрівняють гарантії безпеки легких клієнтів із гарантіями повних клієнтів. + +## Для подальшого читання {#further-reading} + +- [Жолт Фелфоді про легкі клієнти Geth](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Етан Кісслінг про мережеву взаємодію легких клієнтів](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Етан Кісслінг про легкі клієнти після The Merge](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Пайпер Мерріам: звивистий шлях до функціональних легких клієнтів](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/node-architecture/index.md new file mode 100644 index 00000000000..a92cd9b627a --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/node-architecture/index.md @@ -0,0 +1,59 @@ +--- +title: "Архітектура вузла" +description: "Вступ до того, як організовані вузли Ethereum." +lang: uk +--- + +Вузол Ethereum складається з двох клієнтів: [клієнта виконання](/developers/docs/nodes-and-clients/#execution-clients) та [клієнта консенсусу](/developers/docs/nodes-and-clients/#consensus-clients). Щоб вузол міг запропонувати новий блок, він також має запустити [клієнт-валідатор](#validators). + +Коли Ethereum використовував [підтвердження роботи](/developers/docs/consensus-mechanisms/pow/), клієнта виконання було достатньо для запуску повного вузла Ethereum. Однак після впровадження [доказу частки](/developers/docs/consensus-mechanisms/pow/), клієнт виконання має використовуватися разом з іншим програмним забезпеченням, що називається [клієнт консенсусу](/developers/docs/nodes-and-clients/#consensus-clients). + +Діаграма нижче показує відношення між двома клієнтами Ethereum. Два клієнти підключаються до своїх власних відповідних однорангових (P2P) мереж. Окремі P2P-мережі потрібні, оскільки клієнти виконання поширюють транзакції через свою P2P-мережу, що дозволяє їм керувати своїм локальним пулом транзакцій, тоді як клієнти консенсусу поширюють блоки через свою P2P-мережу, забезпечуючи консенсус і зростання ланцюга. + +![](Чи впливає це оновлення на всі вузли та валідаторів Ethereum? node-architecture-text-background.png) + +_Існує кілька варіантів клієнтів виконання, зокрема Erigon, Nethermind та Besu_. + +Щоб ця структура з двох клієнтів працювала, клієнти консенсусу повинні передавати пакети транзакцій клієнту виконання. Клієнт виконання виконує транзакції локально, щоб перевірити, що транзакції не порушують жодних правил Ethereum і що запропоноване оновлення стану Ethereum є правильним. Коли вузол обирається для створення блоку, його екземпляр клієнта консенсусу запитує пакети транзакцій у клієнта виконання, щоб включити їх до нового блоку та виконати для оновлення глобального стану. Клієнт консенсусу керує клієнтом виконання через локальне RPC-з’єднання за допомогою [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). + +## Що робить клієнт виконання? {#execution-client} + +Клієнт виконання відповідає за перевірку, обробку та поширення транзакцій, а також за керування станом і підтримку віртуальної машини Ethereum ([EVM](/developers/docs/evm/)). Він **не** відповідає за створення блоків, їх поширення чи обробку логіки консенсусу. Це входить до компетенції клієнта консенсусу. + +Клієнт виконання створює корисні навантаження виконання — список транзакцій, оновлене дерево стану та інші дані, пов’язані з виконанням. Клієнти консенсусу включають корисне навантаження виконання в кожен блок. Клієнт виконання також відповідає за повторне виконання транзакцій у нових блоках, щоб переконатися в їхній дійсності. Виконання транзакцій відбувається на вбудованому комп’ютері клієнта виконання, відомому як [віртуальна машина Ethereum (EVM)](/developers/docs/evm). + +Клієнт виконання також пропонує інтерфейс користувача для Ethereum через [методи RPC](/developers/docs/apis/json-rpc), які дозволяють користувачам надсилати запити до блокчейну Ethereum, подавати транзакції та розгортати смарт-контракти. Зазвичай виклики RPC обробляються бібліотекою, як-от [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), або інтерфейсом користувача, наприклад, браузерним гаманцем. + +Отже, клієнт виконання — це: + +- шлюз користувача до Ethereum +- місце, де знаходиться віртуальна машина Ethereum, стан Ethereum і пул транзакцій. + +## Що робить клієнт консенсусу? {#consensus-client} + +Клієнт консенсусу обробляє всю логіку, яка дозволяє вузлу залишатися синхронізованим із мережею Ethereum. Це включає отримання блоків від пірів і запуск алгоритму вибору форку, щоб гарантувати, що вузол завжди слідує за ланцюгом із найбільшим накопиченням атестацій (зважених за ефективними балансами валідаторів). Подібно до клієнта виконання, клієнти консенсусу мають власну P2P-мережу, через яку вони обмінюються блоками та атестаціями. + +Клієнт консенсусу не бере участі в атестації або пропозиції блоків — це робить валідатор, необов’язковий додаток до клієнта консенсусу. Клієнт консенсусу без валідатора лише відстежує верхівку ланцюга, дозволяючи вузлу залишатися синхронізованим. Це дозволяє користувачеві здійснювати транзакції з Ethereum за допомогою свого клієнта виконання, будучи впевненим, що він знаходиться на правильному ланцюгу. + +## Валідатори {#validators} + +Стейкінг і запуск програмного забезпечення валідатора дають вузлу право бути обраним для пропозиції нового блоку. Оператори вузлів можуть додати валідатора до своїх клієнтів консенсусу, внісши 32 ETH на депозитний контракт. Клієнт-валідатор постачається в комплекті з клієнтом консенсусу і може бути доданий до вузла в будь-який час. Валідатор обробляє атестації та пропозиції блоків. Це також дозволяє вузлу отримувати винагороди або втрачати ETH через штрафи чи слешинг. + +[Докладніше про стейкінг](/staking/). + +## Порівняння компонентів вузла {#node-comparison} + +| Клієнт виконання | Клієнт консенсусу | Валідатор | +| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | +| Поширює транзакції через свою P2P-мережу | Поширює блоки та атестації через свою P2P-мережу | Пропонує блоки | +| Виконує/повторно виконує транзакції | Запускає алгоритм вибору форку | Нараховує винагороди/штрафи | +| Перевіряє вхідні зміни стану | Відстежує верхівку ланцюга | Створює атестації | +| Керує деревами стану та квитанцій | Керує станом Beacon Chain (містить інформацію про консенсус та виконання) | Вимагає стейкінгу 32 ETH | +| Створює корисне навантаження виконання | Відстежує накопичену випадковість у RANDAO (алгоритм, що забезпечує перевірену випадковість для вибору валідаторів та інших операцій консенсусу) | Може бути підданий слешингу | +| Надає JSON-RPC API для взаємодії з Ethereum | Відстежує обґрунтування та фіналізацію | | + +## Для подальшого читання {#further-reading} + +- [Доказ частки](/developers/docs/consensus-mechanisms/pos) +- [Пропозиція блоку](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [Винагороди та штрафи валідатора](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/nodes-as-a-service/index.md new file mode 100644 index 00000000000..9b5d6d9a26f --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -0,0 +1,418 @@ +--- +title: "Вузли як сервіс" +description: "Загальне початкове уявлення про сервіси вузлів, переваг і недоліків і відомих провайдерів." +lang: uk +sidebarDepth: 2 +--- + +## Вступ {#Introduction} + +Запуск власного [вузла Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) може бути складним завданням, особливо на початковому етапі або під час швидкого масштабування. Існує [низкa сервісів](#popular-node-services), які запускають для вас оптимізовані інфраструктури вузлів, щоб ви могли зосередитися на розробці свого застосунку або продукту. Ми розтлумачимо як служать центри надання послуг, переваги і недоліки їхніх використань і перелік провайдерів, якщо ви зацікавленні у тому, щоб розпочати роботу. + +## Передумови {#prerequisites} + +Якщо ви ще не розумієте, що таке вузли та клієнти, перегляньте розділ [Вузли та клієнти](/developers/docs/nodes-and-clients/). + +## Стейкери {#stakoooooooooooooors} + +Соло-стейкери повинні запускати власну інфраструктуру, а не покладатися на сторонніх постачальників. Це означає запуск клієнта-виконавця в поєднанні з клієнтом консенсусу. До [The Merge](/roadmap/merge) можна було запускати лише клієнт консенсусу та використовувати централізованого постачальника для даних виконання; тепер це неможливо — соло-стейкер повинен запускати обидва клієнти. Однак існують сервіси, які полегшують цей процес. + +[Дізнайтеся більше про запуск вузла](/developers/docs/nodes-and-clients/run-a-node/). + +Сервіси, описані на цій сторінці, призначені для вузлів, що не беруть участі у стейкінгу. + +## Як діють сервіси надання послуг? {#how-do-node-services-work} + +Постачальники сервісу вузла запускають розподілених клієнтів вузла замість вас. + +Ці послуги зазвичай надають ключ API, який ви можете використовуати лдя запису і читання з blockchain. Вони часто надають доступ до [тестових мереж Ethereum](/developers/docs/networks/#ethereum-testnets) на додачу до основної мережі. + +Деякі сервіси пропонують ваш власний вузол, яким вони керують, в той час як інші використовують балансери навантаження для розповсюдження активності через вузли. + +Майже всі послуги вузла надзвичайно легко інтегрувати, за допомогою зміни одного рядка вашого коду для зміни власного вузла чи перемикання між самими сервісами. + +Часто сервіси вузлів запускають різноманітні [клієнти вузлів](/developers/docs/nodes-and-clients/#execution-clients) і [типи](/developers/docs/nodes-and-clients/#node-types), що дає змогу отримувати доступ до повних і архівних вузлів на додаток до специфічних методів клієнта в одному API. + +Важливо зазначити, що сервіси надання послуг не повинні зберігати ваші приватні паролі чи інформацію. + +## Які вигоди можна здобути, використовуючи сервіс надання послуг? {#benefits-of-using-a-node-service} + +Головна перевага використання сервісу надання послуг - це те, що не потрібно витрачати час на технічне обслуговування чи на самостійне керування сервісами. Це дає вам можливість сфокусуватись на розробці вашого продукту, аніж на турботах про технічне обслуговування інфраструктури. + +Керування власними вузлами може бути дороговартісним від зберігання для пропускної здатності до цінного часу інженерії. Такі речі, як розгортання додаткових вузлів під час масштабування, оновлення вузлів до останніх версій і забезпечення узгодженості стану, можуть відволікати від створення бажаного продукту Web3 і витрачання на нього ресурсів. + +## Які недоліки у використанні сервіса вузла? {#cons-of-using-a-node-service} + +Користуючись сервісом вузла, ви централізуєте інфраструктуру вашого продукту. Саме тому проекти, які вважають децентралізацію важливішою, можуть надавати перевагу вузлам із самохостингом, а не аутсорсингу третій стороні. + +Дізнайтеся більше про [переваги запуску власного вузла](/developers/docs/nodes-and-clients/#benefits-to-you). + +## Популярні сервіси вузлів {#popular-node-services} + +Ось список деяких найбільш відомих постачальників сервісних послуг Ethereum, не соромтеся додавати й інші, якщо є пропущені! Кожен вузловий сервіс пропонує різні переваги і функції, на додачу до безкоштовних чи платних рівнів. Перед тим, як приймати рішення, вам слід визначити, які зних найбільше підходять вашим потребам. + +- [**Alchemy**](https://alchemy.com/) + - [Документація](https://www.alchemy.com/docs/) + - Особливості + - Найбільший безкоштовний рівень із 300 млн обчислювальних одиниць на місяць (~30 млн запитів getLatestBlock) + - Підтримка кількох мереж для Polygon, Starknet, Optimism, Arbitrum + - Забезпечує роботу ~70 % найбільших dApps на Ethereum та обсягу транзакцій DeFi + - Сповіщення через вебхуки в реальному часі за допомогою Alchemy Notify + - Найкраща у своєму класі підтримка та надійність / стабільність + - API для NFT від Alchemy + - Інформаційна панель із Провідником запитів, Спостерігачем за мемпулом і Компонувальником + - Інтегрований доступ до крану тестової мережі + - Активна спільнота розробників у Discord із 18 тис. користувачів + +- [**Allnodes**](https://www.allnodes.com/) + - [Документація](https://docs.allnodes.com/) + - Особливості + - Немає обмежень на кількість запитів із токеном PublicNode, створеним на сторінці портфоліо Allnodes. + - Безкоштовні кінцеві точки RPC, орієнтовані на конфіденційність (понад 100 блокчейнів) на [PublicNode](https://www.publicnode.com) + - Виділені вузли без обмежень на кількість запитів для понад 90 блокчейнів + - Виділені архівні вузли для понад 30 блокчейнів + - Доступно в 3 регіонах (США, ЄС, Азія) + - Знімки для понад 100 блокчейнів на [PublicNode](https://www.publicnode.com/snapshots) + - Цілодобова технічна підтримка з SLA безвідмовної роботи 99,90 %–99,98 % (залежить від тарифу). + - Вартість за годину + - Оплата кредитною карткою, PayPal або криптовалютою + +- [**All That Node**](https://allthatnode.com/) + - [Документація](https://docs.allthatnode.com/) + - Особливості + - 50 000 запитів на день на безкоштовному тарифі + - Підтримка понад 40 протоколів + - Підтримка API JSON-RPC (EVM, Tendermint), REST і Websocket + - Необмежений доступ до архівних даних + - Цілодобова технічна підтримка та безвідмовна робота понад 99,9 % + - Кран доступний у кількох мережах + - Необмежений доступ до кінцевих точок із необмеженою кількістю ключів API + - Підтримка API трасування/налагодження + - Автоматизовані оновлення + +- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) + - [Документація](https://aws.amazon.com/managed-blockchain/resources/) + - Особливості + - Повністю керовані вузли Ethereum + - Доступно в шести регіонах + - JSON-RPC через HTTP та безпечні WebSockets + - Підтримує 3 мережі + - SLA, цілодобова підтримка AWS + - Go-ethereum і Lighthouse + +- [**Ankr**](https://www.ankr.com/) + - [Документація](https://docs.ankr.com/) + - Особливості + - Протокол Ankr — відкритий доступ до кінцевих точок Public RPC API для понад 8 мереж + - Балансування навантаження та моніторинг стану вузлів для швидкого та надійного шлюзу до найближчого доступного вузла + - Преміум-рівень, що надає кінцеву точку WSS і необмежену кількість запитів + - Розгортання повного вузла та вузла валідатора в один клік для понад 40 мереж + - Сплачуй за час користування + - Інструменти аналізу + - Панель керування + - Кінцеві точки RPC, HTTPS і WSS + - Пряма підтримка + +- [**Blast**](https://blastapi.io/) + - [Документація](https://docs.blastapi.io/) + - Особливості + - Підтримка RPC і WSS + - Хостинг вузлів у кількох регіонах + - Децентралізована інфраструктура + - Публічний API + - Спеціальний безкоштовний план + - Підтримка кількох мереж (понад 17 блокчейнів) + - Архівні вузли + - Цілодобова підтримка в Discord + - Цілодобовий моніторинг і сповіщення + - Загальний SLA 99,9% + - Оплата криптовалютою + +- [**BlockDaemon**](https://blockdaemon.com/) + - [Документація](https://ubiquity.docs.blockdaemon.com/) + - Переваги + - Панель керування + - База окремого вузла + - Аналіз + +- [**BlockPI**](https://blockpi.io/) + - [Документація](https://docs.blockpi.io/) + - Особливості + - Надійна та розподілена структура вузлів + - До 40 кінцевих точок HTTPS і WSS + - Безкоштовний пакет для реєстрації та місячний пакет + - Метод трасування + підтримка архівних даних + - Пакети з терміном дії до 90 днів + - Індивідуальний план та оплата по мірі використання + - Оплата криптовалютою + - Пряма підтримка та технічна підтримка + +- [**Chainbase**](https://www.chainbase.com/) + - [Документація](https://docs.chainbase.com) + - Особливості + - Високодоступний, швидкий і масштабований сервіс RPC + - Підтримка кількох мереж + - Безкоштовні тарифи + - Зручна інформаційна панель + - Надає послуги даних блокчейну поза межами RPC + +- [**Chainstack**](https://chainstack.com/) + - [Документація](https://docs.chainstack.com/) + - Особливості + - Безкоштовні спільні вузли + - Вузли загального архіву + - Підтримка GraphQL + - RPC і WSS кінцеві точки + - Виділені повні та архівні вузли + - Висока швидкість синхронізації для виділених розгортань + - Використання власної хмари + - Вартість за годину + - Підтримка 24/7 + +- [**dRPC**](https://drpc.org/) + - [Документація](https://drpc.org/docs) + - NodeCloud: інфраструктура RPC за принципом «підключи й працюй» від 10 доларів США — повна швидкість, без обмежень + - Функції NodeCloud: + - Підтримка API для 185 мереж + - Розподілений пул із понад 40 постачальників + - Глобальне покриття з дев'ятьма (9) геокластерами + - Система балансування навантаження на основі штучного інтелекту + - Фіксована ціна з оплатою за фактом використання — без підвищення цін, без терміну дії, без блокувань + - Необмежена кількість ключів, детальні налаштування ключів, ролі в команді, захист фронтенду + - Фіксована ставка методів 20 обчислювальних одиниць (CU) за метод + - [Список ланцюжків публічних кінцевих точок](https://drpc.org/chainlist) + - [Калькулятор цін](https://drpc.org/pricing#calculator) + - NodeCore: стек із відкритим вихідним кодом для організацій, які хочуть мати повний контроль + +- [**GetBlock**](https://getblock.io/) + - [Документація](https://getblock.io/docs/get-started/authentication-with-api-key/) + - Особливості + - Доступ до більш, ніж 40 сервісів блокчейну + - 40 тисяч безкоштовних запитів у день + - Необмежена кількість ключів API + - Висока швидкість з'єднання в 1ГБ/сек + - Відслідити + Архівувати + - Розширена аналітика + - Автоматизовані оновлення + - Технічна підтримка + +- [**InfStones**](https://infstones.com/) + - Особливості + - Можливість безплатного користування + - Сплачуй за час користування + - Аналіз + - Панель керування + - Унікальні кінцеві точки API + - Виділені повні вузли + - Висока швидкість синхронізації для виділених розгортань + - Підтримка 24/7 + - Доступ до більш, ніж 50 сервісів блокчейну + +- [**Infura**](https://infura.io/) + - [Документація](https://infura.io/docs) + - Особливості + - Можливість безплатного користування + - Сплачуй за час користування + - Безплатна архівація даних + - Пряма підтримка + - Панель керування + +- [**Kaleido**](https://kaleido.io/) + - [Документація](https://docs.kaleido.io/) + - Особливості + - Безкоштовний стартовий тариф + - Розгортання вузла Ethereum в один клік + - Клієнти та алгоритми, що налаштовуються (Geth, Quorum і Besu || PoA, IBFT і Raft) + - Понад 500 адміністративних і сервісних API + - RESTful-інтерфейс для надсилання транзакцій Ethereum (на базі Apache Kafka) + - Вихідні потоки для доставки подій (на базі Apache Kafka) + - Велика колекція "offchain" та допоміжних сервісів (наприклад, двосторонній зашифрований транспорт повідомлень) + - Просте підключення до мережі з керуванням і контролем доступу на основі ролей + - Складне керування користувачами як для адміністраторів, так і для кінцевих користувачів + - Високомасштабована, відмовостійка інфраструктура корпоративного рівня + - Керування приватними ключами Cloud HSM + - Прив'язка до основної мережі Ethereum + - Сертифікації ISO 27k і SOC 2, тип 2 + - Динамічна конфігурація середовища виконання (наприклад, додавання хмарних інтеграцій, зміна вхідних трафіків вузлів тощо) + - Підтримка мультихмарних, мультирегіональних і гібридних розгортань + - Просте ціноутворення SaaS із погодинною оплатою + - SLA та цілодобова підтримка + +- [**Lava Network**](https://www.lavanet.xyz/) + - [Документація](https://docs.lavanet.xyz/) + - Особливості + - Безкоштовне використання тестової мережі + - Децентралізоване резервування для високого часу безвідмовної роботи + - Із відкритим кодом + - Повністю децентралізований SDK + - Інтеграція з Ethers.js + - Інтуїтивно зрозумілий інтерфейс керування проєктами + - Цілісність даних на основі консенсусу + - Підтримка кількох ланцюжків + +- [**Moralis**](https://moralis.io/) + - [Документація](https://docs.moralis.io/) + - Особливості + - Безкоштовні спільні вузли + - Безкоштовні загальні архівні сервіси + - Політики приватності (без журналів) + - Підтримка кросчейну + - Сплачуй за час користування + - Панель керування + - Унікальний комплект для розробки програмного забезпечення від Ethereum + - Унікальні кінцеві точки API + - Пряма технічна підтримка + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [Документація](https://docs.nodereal.io/docs/introduction) + - Особливості + - Надійні, швидкі та масштабовані сервіси RPC API + - Розширений API для розробників Web3 + - Підтримка кількох мереж + - Почніть безкоштовно + +- [**NOWNodes**](https://nownodes.io/) + - [Документація](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - Особливості + - Доступ до більш, ніж 50 сервісів блокчейну + - Безкоштовний ключ API + - Інструменти дослідження блоків + - Час відповіді API ⩽ 1 сек + - Команда підтримки 24/7 + - Персональний менеджер облікового запису + - Спільні, архівні, резервні та виділені вузли + +- [**Pocket Network**](https://www.pokt.network/) + - [Документація](https://docs.pokt.network/home/) + - Особливості + - Децентралізований протокол RPC і Ринок + - 1 мільйон безкоштовних запитів (максимум 2, до кінцевої точки) + - [Публічні кінцеві точки](https://docs.pokt.network/developers/public-endpoints) + - Додаток Pre-Stake+ (якщо вам необхідно мати більше ніж 1 мільйон запитів на день) + - Підтримування більше 15 Blockchains + - Більше 6400 сервісів, які заробляють POKT для обслуговування додатків + - Підтримка архівного вузла, архівного вузла з трасуванням і вузла тестової мережі + - Різноманітність клієнтської бази мережі сервісу Ethereum + - Немає єдиної точки збою + - Відсутній час простою + - Економічно ефективна токеноміка з майже нульовими витратами (зробіть стейкінг POKT один раз для отримання пропускної здатності мережі) + - Відсутні незворотні щомісячні затрати, перетворіть вашу інфраструктуру у цінну власність + - Балансування навантаження вбудоване в Протокол + - Нескінченно масштабуйте кількість запитів на день і сервісів на годину в міру просування + - Найбільш приватна, стійка до цензури опція + - Практична підтримка розробника + - Інформаційна панель [Pocket Portal](https://bit.ly/ETHorg_POKTportal) та аналітика + +- [**QuickNode**](https://www.quicknode.com) + - [Документація](https://www.quicknode.com/docs/) + - Особливості + - Цілодобова технічна підтримка та спільнота розробників у Discord + - Географічно збалансована мережа з низькою затримкою на кількох хмарах/фізичних серверах + - Підтримка декількох ланцюжків (Optimism, Arbitrum, Polygon + 11 інших) + - Проміжні рівні для швидкості та стабільності (маршрутизація викликів, кеш, індексація) + - Моніторинг смартконтрактів через вебхуки + - Інтуїтивно зрозуміла інформаційна панель, набір аналітики, компонувальник RPC + - Розширені функції безпеки (JWT, маскування, білі списки) + - API даних та аналітики NFT + - [Сертифіковано SOC2](https://www.quicknode.com/security) + - Підходить як для розробників, так і для підприємств + +- [**Rivet**](https://rivet.cloud/) + - [Документація](https://rivet.readthedocs.io/en/latest/) + - Особливості + - Можливість безплатного користування + - Сплачуй за час користування + +- [**SenseiNode**](https://senseinode.com) + - [Документація](https://docs.senseinode.com/) + - Особливості + - Виділені та спільні вузли + - Панель керування + - Хостинг поза AWS у кількох хостинг-провайдерів у різних місцях Латинської Америки + - Клієнти Prysm і Lighthouse + +- [**SettleMint**](https://console.settlemint.com/) + - [Документація](https://docs.settlemint.com/) + - Особливості + - Безплатна пробна версія + - Сплачуй за час користування + - Підтримка GraphQL + - RPC і WSS кінцеві точки + - Виділені повні вузли + - Використання власної хмари + - Інструменти аналізу + - Панель керування + - Вартість за годину + - Пряма підтримка + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [Документація](https://docs.tenderly.co/web3-gateway/web3-gateway) + - Особливості + - Безкоштовний рівень, що включає 25 мільйонів одиниць Tenderly на місяць + - Вільний доступ до історичної інформації + - До 8 разів швидші робочі навантаження з великою кількістю операцій читання + - 100% узгоджений доступ для читання + - Кінцеві точки JSON-RPC + - Конструктор RPC-запитів на основі інтерфейсу користувача та попередній перегляд запитів + - Тісно інтегрований з інструментами розробки, налагодження та тестування Tenderly + - Симуляції транзакцій + - Аналітика використання та фільтрація + - Просте керування ключами доступу + - Спеціалізована інженерна підтримка через чат, електронну пошту та Discord + +- [**Tokenview**](https://services.tokenview.io/) + - [Документація](https://services.tokenview.io/docs?type=nodeService) + - Особливості + - Цілодобова технічна підтримка та спільнота розробників у Telegram + - Підтримка кількох мереж (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic) + - Кінцеві точки RPC і WSS відкриті для використання + - Необмежений доступ до API архівних даних + - Інформаційна панель із Провідником запитів та Спостерігачем за мемпулом + - API даних NFT і сповіщення через вебхуки + - Оплата криптовалютою + - Зовнішня підтримка для додаткових вимог до поведінки + +- [**Watchdata**](https://watchdata.io/) + - [Документація](https://docs.watchdata.io/) + - Особливості + - Надійність даних + - Безперебійне з'єднання без простоїв + - Автоматизація процесів + - Безкоштовні тарифи + - Високі ліміти, які підійдуть будь-якому користувачу + - Підтримка різних вузлів + - Масштабування ресурсів + - Висока швидкість обробки + +- [**ZMOK**](https://zmok.io/) + - [Документація](https://docs.zmok.io/) + - Особливості + - Front-running як послуга + - Глобальний мемпул транзакцій із методами пошуку/фільтрації + - Необмежена комісія за транзакцію та нескінченний газ для надсилання транзакцій + - Найшвидше отримання нового блоку та читання блокчейну + - Гарантія найкращої ціни за виклик API + +- [**Zeeve**](https://www.zeeve.io/) + - [Документація](https://www.zeeve.io/docs/) + - Особливості + - Платформа автоматизації корпоративного рівня без коду, що забезпечує розгортання, моніторинг і керування вузлами та мережами блокчейну + - Понад 30 підтримуваних протоколів та інтеграцій, і їхня кількість зростає + - Додаткові сервіси інфраструктури Web3, як-от децентралізоване сховище, децентралізована ідентифікація та API даних реєстру блокчейну для реальних сценаріїв використання + - Цілодобова підтримка та проактивний моніторинг забезпечують постійний стан справності вузлів. + - Кінцеві точки RPC пропонують автентифікований доступ до API, просте керування за допомогою інтуїтивно зрозумілої інформаційної панелі та аналітики. + - Надає на вибір як керовані хмари, так і варіант використання власної хмари, а також підтримує всіх основних хмарних провайдерів, як-от AWS, Azure, Google Cloud, Digital Ocean, і локальне розгортання. + - Ми використовуємо інтелектуальну маршрутизацію, щоб щоразу звертатися до найближчого до вашого користувача вузла + +## Для подальшого читання {#further-reading} + +- [Список сервісів вузлів Ethereum](https://ethereumnodes.com/) + +## Пов'язані теми {#related-topics} + +- [Вузли та клієнти](/developers/docs/nodes-and-clients/) + +## Пов'язані посібники {#related-tutorials} + +- [Початок роботи з розробкою на Ethereum за допомогою Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [Посібник із надсилання транзакцій за допомогою web3 та Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/uk/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/uk/developers/docs/nodes-and-clients/run-a-node/index.md new file mode 100644 index 00000000000..5812a0fac49 --- /dev/null +++ b/public/content/translations/uk/developers/docs/nodes-and-clients/run-a-node/index.md @@ -0,0 +1,484 @@ +--- +title: "Прискорте ваш власний Ethereum вузол" +description: "Загальний вступ до самостійного використання клієнта Ethereum." +lang: uk +sidebarDepth: 2 +--- + +Створення власного вузла надає вам різні переваги, відкриває нові можливості та допомагає підтримувати екосистему. Ця сторінка допоможе вам підготувати ваш власний вузол та взяти участь в затвердженні транзакцій Ethereum. + +Зверніть увагу, що після [The Merge](/roadmap/merge) для запуску вузла Ethereum потрібні два клієнти: клієнт **виконавчого рівня (EL)** і клієнт **рівня консенсусу (CL)**. На цій сторінці буде показано, як установити, налаштувати та підключити ці два клієнти для запуску вузла Ethereum. + +## Передумови {#prerequisites} + +Ви повинні розуміти, що таке вузол Ethereum і чому можете бути краще запустити клієнт. Це описано в розділі [Вузли та клієнти](/developers/docs/nodes-and-clients/). + +Якщо ви не знайомі з темою запуску вузла або шукаєте менш технічний шлях, ми рекомендуємо спочатку ознайомитися з нашим зручним вступом про [запуск вузла Ethereum](/run-a-node). + +## Вибір підходу {#choosing-approach} + +Перший крок в налаштуванні вашого вузла - вибір вашого підходу. Виходячи з вимог і різноманітних можливостей, ви повинні вибрати реалізацію клієнта (як клієнта виконання, так і клієнта консенсусу), середовище (апаратне забезпечення, система) та параметри для налаштувань клієнта. + +Ця сторінка допоможе вам прийняти ці рішення та знайти найбільш підходящий спосіб запуску вашого екземпляра Ethereum. + +Щоб вибрати з реалізацій клієнтів, перегляньте всі доступні, готові для Mainnet [клієнти виконання](/developers/docs/nodes-and-clients/#execution-clients), [клієнти консенсусу](/developers/docs/nodes-and-clients/#consensus-clients) та дізнайтеся про [різноманітність клієнтів](/developers/docs/nodes-and-clients/client-diversity). + +Вирішіть, чи запускати програмне забезпечення на власному [апаратному забезпеченні чи в хмарі](#local-vs-cloud), враховуючи [вимоги](#requirements) клієнтів. + +Після підготовки середовища встановіть вибрані клієнти або за допомогою [зручного для початківців інтерфейсу](#automatized-setup), або [вручну](#manual-setup) за допомогою терміналу з розширеними опціями. + +Коли вузол запущений і синхронізується, ви готові [використовувати його](#using-the-node), але не забувайте стежити за його [обслуговуванням](#operating-the-node). + +![Налаштування клієнта](./diagram.png) + +### Середовище та апаратне забезпечення {#environment-and-hardware} + +#### Локально чи в хмарі {#local-vs-cloud} + +Клієнти Ethereum можуть працювати на комп’ютерах споживчого класу і не потребують спеціального обладнання, як, наприклад, машини для майнінгу. Тому у вас є різні варіанти розгортання вузла залежно від ваших потреб. +Для спрощення розглянемо запуск вузла як і на локальному фізичному пристрої, так і на хмарному сервері: + +- Хмарне сховище + - Провайдери пропонують високий час безвідмовної роботи сервера та статичні загальнодоступні IP-адреси + - Отримання виділеного або віртуального сервера може бути зручніше, ніж створення власного сервера + - Компроміс довіряє третій особі - постачальнику сервера + - Через необхідний обсяг сховища для повного вузла ціна орендованого сервера може бути високою +- Власне обладнання + - Більш надійний та незалежний підхід + - Інвестувати треба лише раз + - Можливість придбання попередньо налаштованих машин + - Ви повинні фізично готувати, обслуговувати та потенційно усувати несправності машини та мережі + +Обидва варіанти мають різні переваги, які були підсумовані вище. Якщо ви шукаєте хмарне рішення, окрім багатьох традиційних постачальників хмарних обчислень, є також послуги, орієнтовані на запуск вузлів. Перегляньте [вузли як послугу](/developers/docs/nodes-and-clients/nodes-as-a-service/), щоб дізнатися більше про варіанти розміщених вузлів. + +#### Апаратне забезпечення {#hardware} + +Однак резистентна до цензури, децентралізована мережа не повинна покладатися на постачальників хмарного забезпечення. Натомість запуск вузла на власному локальному обладнанні є кращим для екосистеми. [Оцінки](https://www.ethernodes.org/networkType/cl/Hosting) показують, що значна частина вузлів працює в хмарі, що може стати єдиною точкою відмови. + +Клієнти Ethereum можуть працювати на вашому комп’ютері, ноутбуці, сервері або навіть на одноплатному комп’ютері. Хоча запускати клієнти на персональному комп’ютері можливо, наявність виділеної машини лише для вашого вузла може значно підвищити його продуктивність і безпеку, мінімізуючи вплив на ваш основний комп’ютер. + +Використовувати власне обладнання може бути дуже легко. Існує багато простих варіантів, а також розширені налаштування для більш технічно підкованих людей. Тож давайте розглянемо вимоги та засоби для запуску клієнтів Ethereum на вашій машині. + +#### Вимоги {#requirements} + +Вимоги до апаратного забезпечення розрізняються залежно від клієнта, але зазвичай не такі високі, оскільки вузол просто повинен залишатися синхронізованим. Не плутайте це з майнінгом, який вимагає набагато більшої обчислювальної потужності. Однак час синхронізації і продуктивність поліпшуються з більш потужним апаратним забезпеченням. + +Перед встановленням будь-якого клієнта переконайтеся, що на вашому комп'ютері достатньо ресурсів для його запуску. Нижче ви можете знайти мінімальні та рекомендовані вимоги. + +Вузьким місцем для вашого апаратного забезпечення є переважно дисковий простір. Синхронізація блокчейну Ethereum дуже інтенсивна щодо операцій введення/виведення та вимагає багато місця. Найкраще мати **твердотільний накопичувач (SSD)** із сотнями ГБ вільного місця навіть після синхронізації. + +Розмір бази даних і швидкість початкової синхронізації залежать від вибраного клієнта, його конфігурації та [стратегії синхронізації](/developers/docs/nodes-and-clients/#sync-modes). + +Також переконайтеся, що ваше інтернет-з’єднання не обмежене [лімітом пропускної здатності](https://wikipedia.org/wiki/Data_cap). Рекомендується використовувати необмежене підключення, оскільки початкова синхронізація та дані, що передаються в мережу, можуть перевищити ваш ліміт. + +##### Операційна система + +Усі клієнти підтримують основні операційні системи - Linux, MacOS, Windows. Це означає, що ви можете запускати вузли на звичайних настільних комп’ютерах або серверах з операційною системою (ОС), яка найкраще підходить для вас. Переконайтеся, що ваша операційна система оновлена, щоб уникнути потенційних проблем і вразливостей безпеки. + +##### Мінімальні вимоги + +- Центральний процесор з 2+ ядрами +- 8 ГБ ОЗП +- 2 ТБ SSD +- 10+ Мбіт/с пропускної здатності + +##### Рекомендовані характеристики + +- Швидкий центральний процесор з 4+ ядрами +- 16 гб + оперативна пам'ять +- Швидкий SSD на 2+ ТБ +- 25+ Мбіт/с пропускної здатності + +Режим синхронізації та клієнт, які ви виберете, вплинуть на вимоги до простору, але ми оцінили дисковий простір, який вам знадобиться для кожного клієнта, нижче. + +| Клієнт | Розмір диска (snap-синхронізація) | Розмір диску (повний архів) | +| ---------- | ---------------------------------------------------- | ---------------------------------------------- | +| Besu | 800 ГБ+ | 12 ТБ+ | +| Erigon | Недоступно | 2,5 ТБ+ | +| Geth | 500 ГБ+ | 12 ТБ+ | +| Nethermind | 500 ГБ+ | 12 ТБ+ | +| Reth | Недоступно | 2,2 ТБ+ | + +- Примітка: Erigon і Reth не пропонують snap-синхронізацію, але можливе повне очищення (Full Pruning) (~2 ТБ для Erigon, ~1,2 ТБ для Reth) + +Для клієнтів консенсусу вимога до простору також залежить від реалізації клієнта та ввімкнених функцій (наприклад, слешер валідатора), але зазвичай розраховуйте на ще 200 ГБ, необхідних для даних маяка. З великою кількістю валідаторів навантаження на пропускну здатність також зростає. Ви можете знайти [деталі щодо вимог до клієнта консенсусу в цьому аналізі](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). + +#### Рішення «підключи й працюй» {#plug-and-play} + +Найпростіший варіант запуску вузла на власному обладнанні – це використання пристроїв «підключи й працюй». Попередньо налаштовані машини від постачальників пропонують найпростіший досвід: замовте, підключіть, запустіть. Усе попередньо налаштовано та працює автоматично з інтуїтивно зрозумілим посібником та інформаційною панеллю для моніторингу та керування програмним забезпеченням. + +- [DappNode](https://dappnode.io/) +- [Avado](https://ava.do/) + +#### Ethereum на одноплатному комп’ютері {#ethereum-on-a-single-board-computer} + +Простий і дешевий спосіб запустити вузол Ethereum — це використовувати одноплатний комп’ютер, навіть з архітектурою ARM, як-от Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) надає прості в запуску образи кількох клієнтів виконання та консенсусу для Raspberry Pi та інших плат ARM. + +Такі невеликі, доступні та ефективні пристрої ідеально підходять для запуску вузла вдома, але пам’ятайте про їх обмежену продуктивність. + +## Запуск вузла {#spinning-up-node} + +Фактичне налаштування клієнта можна виконати або за допомогою автоматизованих засобів запуску, або вручну, налаштувавши клієнтське програмне забезпечення безпосередньо. + +Для менш досвідчених користувачів рекомендований підхід — це використання програми запуску, програмного забезпечення, яке проведе вас через установку та автоматизує процес налаштування клієнта. Однак, якщо у вас є досвід роботи з терміналом, кроки для ручного налаштування будуть простими. + +### Налаштування з посібником {#automatized-setup} + +Кілька зручних для користувача проєктів спрямовані на покращення досвіду налаштування клієнта. Ці програми запуску забезпечують автоматичне встановлення та налаштування клієнтів, а деякі навіть пропонують графічний інтерфейс для керованого налаштування та моніторингу клієнтів. + +Нижче наведено кілька проєктів, які допоможуть вам установити та керувати клієнтами лише кількома клацаннями: + +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode — це не лише машина від постачальника. Програмне забезпечення, фактичний засіб запуску вузла та центр керування з багатьма функціями можна використовувати на будь-якому обладнанні. +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) – найшвидший і найпростіший спосіб налаштувати повний вузол. Однорядковий інструмент налаштування та TUI для керування вузлом. Безкоштовно. Відкрите джерело коду. Суспільні блага для Ethereum від соло-стейкерів. Підтримка ARM64 та AMD64. +- [eth-docker](https://eth-docker.net/) — автоматизоване налаштування за допомогою Docker, орієнтоване на простий і безпечний стейкінг, вимагає базових знань терміналу та Docker, рекомендовано для трохи більш просунутих користувачів. +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) — програма запуску для встановлення клієнтів на віддалений сервер через SSH-з’єднання з посібником із налаштування графічного інтерфейсу, центром керування та багатьма іншими функціями. +- [NiceNode](https://www.nicenode.xyz/) — програма запуску з простим користувацьким інтерфейсом для запуску вузла на вашому комп’ютері. Просто виберіть клієнти та запустіть їх кількома клацаннями. Ще в розробці. +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) — інструмент налаштування вузла, який автоматично генерує конфігурацію Docker за допомогою майстра CLI. Написано на Go компанією Nethermind. + +### Ручне налаштування клієнтів {#manual-setup} + +Інший варіант — завантажити, перевірити та налаштувати клієнтське програмне забезпечення вручну. Навіть якщо деякі клієнти пропонують графічний інтерфейс, ручне налаштування все одно вимагає базових навичок роботи з терміналом, але пропонує набагато більшу універсальність. + +Як пояснювалося раніше, налаштування власного вузла Ethereum вимагатиме запуску пари клієнтів консенсусу та виконання. Деякі клієнти можуть містити легкий клієнт іншого типу та синхронізуватися без будь-якого іншого програмного забезпечення. Однак повна бездовірна перевірка вимагає обох реалізацій. + +#### Отримання клієнтського програмного забезпечення {#getting-the-client} + +Спочатку вам потрібно отримати бажане програмне забезпечення [клієнта виконання](/developers/docs/nodes-and-clients/#execution-clients) та [клієнта консенсусу](/developers/docs/nodes-and-clients/#consensus-clients). + +Ви можете просто завантажити виконуваний застосунок або інсталяційний пакет, який підходить для вашої операційної системи та архітектури. Завжди перевіряйте підписи та контрольні суми завантажених пакетів. Деякі клієнти також пропонують репозиторії або образи Docker для полегшення встановлення та оновлення. Усі клієнти мають відкритий вихідний код, тому ви також можете зібрати їх із вихідного коду. Це більш просунутий метод, але в деяких випадках він може знадобитися. + +Інструкції зі встановлення кожного клієнта наведено в документації, посилання на яку є в списках клієнтів вище. + +Ось сторінки випусків клієнтів, де ви можете знайти їхні попередньо зібрані двійкові файли або інструкції зі встановлення: + +##### Клієнти виконання + +- [Besu](https://github.com/hyperledger/besu/releases) +- [Erigon](https://github.com/ledgerwatch/erigon/releases) +- [Geth](https://geth.ethereum.org/downloads/) +- [Nethermind](https://downloads.nethermind.io/) +- [Reth](https://reth.rs/installation/installation.html) + +Варто також зазначити, що різноманітність клієнтів є [проблемою на рівні виконання](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Читачам рекомендується розглянути можливість запуску клієнта виконання, що є в меншості. + +##### Клієнти консенсусу + +- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source/) (Не надає попередньо зібраний двійковий файл, лише образ Docker або для збирання з вихідного коду) +- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) +- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) +- [Teku](https://github.com/ConsenSys/teku/releases) + +[Різноманітність клієнтів](/developers/docs/nodes-and-clients/client-diversity/) має вирішальне значення для вузлів консенсусу, що запускають валідаторів. Якщо більшість валідаторів використовують одну реалізацію клієнта, безпека мережі під загрозою. Тому рекомендується розглянути можливість вибору клієнта, що є в меншості. + +[Перегляньте останнє використання мережевих клієнтів](https://clientdiversity.org/) та дізнайтеся більше про [різноманітність клієнтів](/developers/docs/nodes-and-clients/client-diversity). + +##### Перевірка програмного забезпечення + +Під час завантаження програмного забезпечення з Інтернету рекомендується перевіряти його цілісність. Цей крок є необов'язковим, але особливо з таким важливим елементом інфраструктури, як клієнт Ethereum, важливо знати про потенційні вектори атак і уникати їх. Якщо ви завантажили попередньо зібраний двійковий файл, ви повинні довіряти йому і ризикувати тим, що зловмисник може замінити виконуваний файл на шкідливий. + +Розробники підписують випущені двійкові файли своїми PGP-ключами, щоб ви могли криптографічно перевірити, що ви запускаєте саме те програмне забезпечення, яке вони створили. Вам просто потрібно отримати відкриті ключі, які використовуються розробниками, їх можна знайти на сторінках випусків клієнтів або в документації. Після завантаження випуску клієнта та його підпису ви можете використовувати реалізацію PGP, наприклад, [GnuPG](https://gnupg.org/download/index.html), щоб легко їх перевірити. Ознайомтеся з посібником із перевірки програмного забезпечення з відкритим кодом за допомогою `gpg` на [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) або [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/). + +Інша форма перевірки — переконатися, що хеш, унікальний криптографічний відбиток програмного забезпечення, яке ви завантажили, збігається з тим, що надали розробники. Це навіть простіше, ніж використання PGP, і деякі клієнти пропонують лише цей варіант. Просто запустіть хеш-функцію для завантаженого програмного забезпечення та порівняйте результат із тим, що на сторінці випуску. Наприклад: + +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### Налаштування клієнта {#client-setup} + +Після встановлення, завантаження або компіляції клієнтського програмного забезпечення ви готові його запустити. Це лише означає, що його потрібно виконувати з належною конфігурацією. Клієнти пропонують багаті параметри конфігурації, які можуть увімкнути різні функції. + +Почнемо з опцій, які можуть значно вплинути на продуктивність клієнта та використання даних. [Режими синхронізації](/developers/docs/nodes-and-clients/#sync-modes) представляють різні методи завантаження та перевірки даних блокчейну. Перед запуском вузла вам слід вирішити, яку мережу і режим синхронізації використовувати. Найважливіше, що слід враховувати, — це дисковий простір і час синхронізації, який знадобиться клієнту. Зверніть увагу на документацію клієнта, щоб визначити, який режим синхронізації є стандартним. Якщо це вам не підходить, виберіть інший, виходячи з рівня безпеки, доступних даних і вартості. Крім алгоритму синхронізації, ви також можете налаштувати обрізання різних видів старих даних. Очищення (pruning) дозволяє видаляти застарілі дані, тобто видаляти вузли дерева станів (state trie), недоступні з останніх блоків. + +Інші основні параметри конфігурації — це, наприклад, вибір мережі (Mainnet або тестові мережі), увімкнення кінцевої точки HTTP для RPC або WebSockets тощо. Ви можете знайти всі функції та параметри в документації клієнта. Різні конфігурації клієнта можна встановити, виконавши клієнт із відповідними прапорцями безпосередньо в CLI або файлі конфігурації. Кожен клієнт дещо відрізняється; будь ласка, завжди звертайтеся до його офіційної документації або сторінки довідки для отримання детальної інформації про параметри конфігурації. + +Для тестування ви можете віддати перевагу запуску клієнта в одній із тестових мереж. [Переглянути огляд підтримуваних мереж](/developers/docs/nodes-and-clients/#execution-clients). + +Приклади запуску клієнтів виконання з базовою конфігурацією можна знайти в наступному розділі. + +#### Запуск клієнта виконання {#starting-the-execution-client} + +Перед запуском клієнтського програмного забезпечення Ethereum виконайте останню перевірку готовності вашого середовища. Наприклад, переконайтеся: + +- Достатньо дискового простору з огляду на обрану мережу та режим синхронізації. +- Пам'ять і ЦП не зупиняються іншими програмами. +- Операційну систему оновлено до останньої версії. +- Система має правильний час і дату. +- Ваш маршрутизатор і брандмауер приймають підключення до портів прослуховування. За замовчуванням клієнти Ethereum використовують порт прослуховування (TCP) і порт виявлення (UDP), обидва за замовчуванням 30303. + +Спочатку запустіть клієнта в тестовій мережі, щоб переконатися, що все працює правильно. + +На початку вам потрібно оголосити будь-які налаштування клієнта, які не є стандартними. Ви можете використовувати прапорці або файл конфігурації, щоб оголосити бажану конфігурацію. Набір функцій і синтаксис конфігурації кожного клієнта відрізняються. Перегляньте документацію вашого клієнта для отримання детальної інформації. + +Клієнти виконання та консенсусу взаємодіють через автентифіковану кінцеву точку, зазначену в [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). Щоб підключитися до клієнта консенсусу, клієнт виконання повинен згенерувати [`jwtsecret`](https://jwt.io/) за відомим шляхом. З міркувань безпеки та стабільності клієнти повинні працювати на одній машині, і обидва клієнти повинні знати цей шлях, оскільки він використовується для автентифікації локального з’єднання RPC між ними. Клієнт виконання також повинен визначити порт прослуховування для автентифікованих API. + +Цей токен генерується автоматично клієнтським програмним забезпеченням, але в деяких випадках вам може знадобитися зробити це самостійно. Ви можете згенерувати його за допомогою [OpenSSL](https://www.openssl.org/): + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### Запуск клієнта виконання {#running-an-execution-client} + +У цьому розділі ви дізнаєтеся, як запускати клієнти виконання. Він служить лише прикладом базової конфігурації, яка запустить клієнт із такими налаштуваннями: + +- Вказує мережу для підключення, у наших прикладах — Mainnet + - Натомість ви можете вибрати [одну з тестових мереж](/developers/docs/networks/) для попереднього тестування вашого налаштування +- Визначає каталог даних, де зберігатимуться всі дані, включно з блокчейном + - Переконайтеся, що ви замінили шлях на реальний, наприклад, що вказує на ваш зовнішній диск +- Вмикає інтерфейси для зв’язку з клієнтом + - Включно з JSON-RPC та Engine API для зв’язку з клієнтом консенсусу +- Визначає шлях до `jwtsecret` для автентифікованого API + - Обов’язково замініть приклад шляху на реальний, доступний для клієнтів, наприклад, `/tmp/jwtsecret` + +Зверніть увагу, що це лише базовий приклад, усі інші налаштування будуть встановлені за замовчуванням. Зверніть увагу на документацію кожного клієнта, щоб дізнатися про стандартні значення, налаштування та функції. Для отримання додаткових функцій, наприклад, для запуску валідаторів, моніторингу тощо, зверніться до документації конкретного клієнта. + +> Зауважте, що зворотні косі риски `` у прикладах призначені лише для форматування; прапорці конфігурації можна визначити в одному рядку. + +##### Запуск Besu + +Цей приклад запускає Besu в мережі Mainnet, зберігає дані блокчейну у форматі за замовчуванням у `/data/ethereum`, вмикає JSON-RPC та Engine RPC для підключення клієнта консенсусу. Engine API автентифікується за допомогою токена `jwtsecret`, і дозволені лише виклики з `localhost`. + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +Besu також має опцію запуску, яка поставить низку запитань і згенерує файл конфігурації. Запустіть інтерактивний засіб запуску за допомогою: + +```sh +besu --Xlauncher +``` + +[Документація Besu](https://besu.hyperledger.org/public-networks/get-started/start-node/) містить додаткові параметри та деталі конфігурації. + +##### Запуск Erigon + +Цей приклад запускає Erigon в мережі Mainnet, зберігає дані блокчейну в `/data/ethereum`, вмикає JSON-RPC, визначає, які простори імен дозволені, і вмикає автентифікацію для підключення клієнта консенсусу, що визначається шляхом до `jwtsecret`. + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Erigon за замовчуванням виконує повну синхронізацію з 8 ГБ жорсткого диска, що призведе до більш ніж 2 ТБ архівних даних. Переконайтеся, що `datadir` вказує на диск із достатнім вільним місцем, або зверніть увагу на прапорець `--prune`, який може обрізати різні види даних. Перевірте `--help` Erigon, щоб дізнатися більше. + +##### Запуск Geth + +Цей приклад запускає Geth у мережі Mainnet, зберігає дані блокчейну в `/data/ethereum`, вмикає JSON-RPC та визначає дозволені простори імен. Він також вмикає автентифікацію для підключення клієнта консенсусу, що вимагає шлях до `jwtsecret`, а також опцію, що визначає дозволені з'єднання, у нашому прикладі — лише з `localhost`. + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Перегляньте [документацію для всіх параметрів конфігурації](https://geth.ethereum.org/docs/fundamentals/command-line-options) та дізнайтеся більше про [запуск Geth з клієнтом консенсусу](https://geth.ethereum.org/docs/getting-started/consensus-clients). + +##### Запуск Nethermind + +Nethermind пропонує різні [варіанти встановлення](https://docs.nethermind.io/get-started/installing-nethermind). Пакет містить різні двійкові файли, включно з програмою запуску з керованим налаштуванням, яка допоможе вам інтерактивно створити конфігурацію. Крім того, ви знайдете Runner, який є самим виконуваним файлом, і ви можете просто запустити його з прапорцями конфігурації. JSON-RPC увімкнено за замовчуванням. + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +Документація Nethermind пропонує [повний посібник](https://docs.nethermind.io/get-started/running-node/) із запуску Nethermind з клієнтом консенсусу. + +Клієнт виконання ініціює свої основні функції, обрані кінцеві точки та почне шукати пірів. Після успішного виявлення однорангових партнерів клієнт починає синхронізацію. Клієнт виконання очікуватиме з'єднання від клієнта консенсусу. Поточні дані блокчейну будуть доступні після успішної синхронізації клієнта з поточним станом. + +##### Запуск Reth + +Цей приклад запускає Reth у мережі Mainnet, використовуючи розташування даних за замовчуванням. Вмикає автентифікацію JSON-RPC та Engine RPC для підключення клієнта консенсусу, що визначається шляхом до `jwtsecret`, при цьому дозволені лише виклики з `localhost`. + +```sh +reth node \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +Див. [Налаштування Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), щоб дізнатися більше про каталоги даних за замовчуванням. [Документація Reth](https://reth.rs/run/mainnet.html) містить додаткові опції та деталі конфігурації. + +#### Запуск клієнта консенсусу {#starting-the-consensus-client} + +Клієнт консенсусу повинен бути запущений із правильною конфігурацією порту для встановлення локального з'єднання RPC з клієнтом виконання. Клієнти консенсусу повинні запускатися з відкритим портом клієнта виконання як аргумент конфігурації. + +Клієнту консенсусу також потрібен шлях до `jwt-secret` клієнта виконання для автентифікації з'єднання RPC між ними. Подібно до наведених вище прикладів виконання, кожен клієнт консенсусу має прапорець конфігурації, який приймає шлях до файлу токена jwt як аргумент. Це має відповідати шляху `jwtsecret`, наданому клієнту виконання. + +Якщо ви плануєте запустити валідатор, обов'язково додайте прапорець конфігурації, що вказує адресу Ethereum одержувача комісії. Саме тут накопичуються винагороди в етері для вашого валідатора. Кожен клієнт консенсусу має опцію, наприклад, `--suggested-fee-recipient=0xabcd1`, яка приймає адресу Ethereum як аргумент. + +При запуску вузла Beacon у тестовій мережі ви можете значно заощадити час синхронізації, використовуючи загальнодоступну кінцеву точку для [синхронізації за контрольними точками](https://notes.ethereum.org/@launchpad/checkpoint-sync). + +#### Запуск клієнта консенсусу {#running-a-consensus-client} + +##### Запуск Lighthouse + +Перш ніж запускати Lighthouse, дізнайтеся більше про те, як його встановити та налаштувати, у [книзі Lighthouse](https://lighthouse-book.sigmaprime.io/installation.html). + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### Запуск Lodestar + +Встановіть програмне забезпечення Lodestar, скомпілювавши його або завантаживши образ Docker. Дізнайтеся більше в [документації](https://chainsafe.github.io/lodestar/) та більш повному [посібнику з налаштування](https://hackmd.io/@philknows/rk5cDvKmK). + +```sh +lodestar beacon \ + --dataDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Запуск Nimbus + +Nimbus постачається з клієнтами як консенсусу, так і виконання. Його можна запускати на різних пристроях, навіть з дуже скромною обчислювальною потужністю. +Після [встановлення залежностей і самого Nimbus](https://nimbus.guide/quick-start.html), ви можете запустити його клієнт консенсусу: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Запуск Prysm + +Prysm постачається зі скриптом, який дозволяє легко автоматично встановити його. Деталі можна знайти в [документації Prysm](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/). + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### Запуск Teku + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +Коли клієнт консенсусу підключається до клієнта виконання для читання депозитного контракту та ідентифікації валідаторів, він також підключається до інших пірів вузла Beacon і починає синхронізувати слоти консенсусу з генезису. Як тільки вузол Beacon досягне поточної епохи, API Beacon стане доступним для ваших валідаторів. Дізнайтеся більше про [API вузла Beacon](https://eth2docs.vercel.app/). + +### Додавання валідаторів {#adding-validators} + +Клієнт консенсусу служить вузлом Beacon для підключення валідаторів. Кожен клієнт консенсусу має власне програмне забезпечення валідатора, докладно описане у відповідній документації. + +Запуск власного валідатора дозволяє [соло-стейкінг](/staking/solo/) — найефективніший і найнадійніший метод підтримки мережі Ethereum. Однак це вимагає депозиту в 32 ETH. Щоб запустити валідатор на власному вузлі з меншою сумою, вас може зацікавити децентралізований пул з операторами вузлів без дозволу, наприклад, [Rocket Pool](https://rocketpool.net/node-operators). + +Найпростіший спосіб розпочати стейкінг та генерацію ключів валідатора — це скористатися [стартовою платформою для стейкінгу в тестовій мережі Hoodi](https://hoodi.launchpad.ethereum.org/), яка дозволяє протестувати ваше налаштування, [запустивши вузли в мережі Hoodi](https://notes.ethereum.org/@launchpad/hoodi). Коли ви будете готові до Mainnet, ви можете повторити ці кроки, використовуючи [стартову платформу для стейкінгу в Mainnet](https://launchpad.ethereum.org/). + +Перегляньте [сторінку про стейкінг](/staking), щоб отримати огляд варіантів стейкінгу. + +### Використання вузла {#using-the-node} + +Клієнти виконання пропонують [кінцеві точки RPC API](/developers/docs/apis/json-rpc/), які ви можете використовувати для надсилання транзакцій, взаємодії з або розгортання смартконтрактів у мережі Ethereum різними способами: + +- Вручну викликаючи їх за допомогою відповідного протоколу (наприклад, використовуючи `curl`) +- Підключення наданої консолі (наприклад, `geth attach`) +- Впровадження їх у застосунки за допомогою бібліотек web3, наприклад, [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) + +Різні клієнти мають різні реалізації кінцевих точок RPC. Але існує стандартний JSON-RPC, який ви можете використовувати з кожним клієнтом. Для огляду [прочитайте документацію JSON-RPC](/developers/docs/apis/json-rpc/). Програми, яким потрібна інформація з мережі Ethereum, можуть використовувати цей RPC. Наприклад, популярний гаманець MetaMask дозволяє вам [підключатися до власної кінцевої точки RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), що має значні переваги для конфіденційності та безпеки. + +Усі клієнти консенсусу надають [Beacon API](https://ethereum.github.io/beacon-APIs), який можна використовувати для перевірки стану клієнта консенсусу або завантаження блоків і даних консенсусу, надсилаючи запити за допомогою таких інструментів, як [Curl](https://curl.se). Більше інформації про це можна знайти в документації для кожного клієнта консенсусу. + +#### Доступ до RPC {#reaching-rpc} + +Порт за замовчуванням для JSON-RPC клієнта виконання — `8545`, але ви можете змінити порти локальних кінцевих точок у конфігурації. За замовчуванням інтерфейс RPC доступний лише на локальному хості вашого комп’ютера. Щоб зробити його доступним віддалено, ви можете відкрити його для загального доступу, змінивши адресу на `0.0.0.0`. Це зробить його доступним через локальну мережу та загальнодоступні IP-адреси. У більшості випадків потрібно буде налаштувати порт з перенаправленням на маршрутизатор. + +Підходьте до відкриття портів для Інтернету з обережністю, оскільки це дозволить будь-кому в Інтернеті керувати вашим вузлом. Зловмисники можуть отримати доступ до вашого вузла, щоб атакувати вашу систему або вкрасти ваші кошти, якщо ви використовуєте клієнт як гаманець. + +Способом обійти це є запобігання зміні потенційно шкідливих методів RPC. Наприклад, у Geth ви можете оголосити методи, що підлягають зміні, за допомогою прапорця: `--http.api web3,eth,txpool`. + +Доступ до інтерфейсу RPC можна розширити шляхом розробки API граничного рівня або застосунків вебсервера, як-от Nginx, і підключення їх до локальної адреси та порту вашого клієнта. Використання проміжного рівня також може надати розробникам можливість налаштувати сертифікат для безпечних з'єднань `https` з інтерфейсом RPC. + +Налаштування вебсервера, проксі або зовнішнього Rest API — це не єдиний спосіб надати доступ до кінцевої точки RPC вашого вузла. Ще один спосіб налаштувати загальнодоступну кінцеву точку, що зберігає конфіденційність, — це розмістити вузол у вашій власній службі-цибулині [Tor](https://www.torproject.org/). Це дозволить вам отримати доступ до RPC за межами вашої локальної мережі без статичної загальнодоступної IP-адреси або відкритих портів. Однак використання цієї конфігурації може дозволити доступ до кінцевої точки RPC лише через мережу Tor, яка підтримується не всіма застосунками та може призвести до проблем зі з’єднанням. + +Для цього вам потрібно створити власну [службу-цибулину](https://community.torproject.org/onion-services/). Ознайомтеся з [документацією](https://community.torproject.org/onion-services/setup/) щодо налаштування служби-цибулини, щоб розмістити власну. Ви можете спрямувати його на вебсервер із проксі до порту RPC або просто безпосередньо до RPC. + +Нарешті, одним із найпопулярніших способів надання доступу до внутрішніх мереж є з'єднання через VPN. Залежно від вашого випадку використання та кількості користувачів, яким потрібен доступ до вашого вузла, безпечне з'єднання VPN може бути варіантом. [OpenVPN](https://openvpn.net/) — це повнофункціональний SSL VPN, який реалізує безпечне розширення мережі на рівні 2 або 3 OSI з використанням стандартного протоколу SSL/TLS, підтримує гнучкі методи автентифікації клієнтів на основі сертифікатів, смарт-карт та/або облікових даних імені користувача/пароля, і дозволяє використовувати політики контролю доступу для конкретних користувачів або груп за допомогою правил брандмауера, застосованих до віртуального інтерфейсу VPN. + +### Експлуатація вузла {#operating-the-node} + +Ви повинні регулярно контролювати свій вузол, щоб переконатися, що він працює належним чином. Можливо, вам доведеться періодично проводити технічне обслуговування. + +#### Підтримання вузла в мережі {#keeping-node-online} + +Ваш вузол не повинен бути в мережі постійно, але ви повинні тримати його онлайн якомога довше, щоб він залишався синхронізованим з мережею. Ви можете вимкнути його для перезапуску, але пам’ятайте, що: + +- Вимкнення може зайняти кілька хвилин, якщо останній стан все ще записується на диск. +- Примусове вимкнення може пошкодити базу даних, що вимагатиме повторної синхронізації всього вузла. +- Ваш клієнт не буде синхронізуватися з мережею, і його доведеться повторно синхронізувати, коли ви його перезавантажите. Хоча вузол може почати синхронізацію з місця останнього вимкнення, процес може зайняти час залежно від того, як довго він був офлайн. + +_Це не стосується вузлів-валідаторів рівня консенсусу._ Вимкнення вашого вузла вплине на всі залежні від нього служби. Якщо ви запускаєте вузол для _стейкінгу_, ви повинні намагатися мінімізувати час простою якомога більше. + +#### Створення служб клієнта {#creating-client-services} + +Розгляньте можливість створення служби для автоматичного запуску ваших клієнтів під час завантаження. Наприклад, на серверах Linux гарною практикою буде створення служби, наприклад, за допомогою `systemd`, яка виконує клієнт із належною конфігурацією під користувачем з обмеженими привілеями та автоматично перезапускається. + +#### Оновлення клієнтів {#updating-clients} + +Вам потрібно підтримувати ваше клієнтське програмне забезпечення в актуальному стані з останніми виправленнями безпеки, функціями та [EIP](/eips/). Особливо перед [хардфорками](/ethereum-forks/) переконайтеся, що ви використовуєте правильні версії клієнта. + +> Перед важливими оновленнями мережі EF публікує допис у своєму [блозі](https://blog.ethereum.org). Ви можете [підписатися на ці оголошення](https://blog.ethereum.org/category/protocol#subscribe), щоб отримувати сповіщення на свою пошту, коли ваш вузол потребує оновлення. + +Оновлення клієнтів дуже просте. Кожен клієнт має конкретні інструкції у своїй документації, але процес, як правило, полягає лише в тому, щоб завантажити останню версію та перезапустити клієнт з новим виконуваним файлом. Клієнт повинен продовжити роботу з того місця, де зупинився, але із застосованими оновленнями. + +Кожна реалізація клієнта має читабельний рядок версії, який використовується в протоколі peer-to-peer, але також доступний з командного рядка. Цей рядок версії дозволяє користувачам перевіряти, чи працює коректно версія, а також дозволяє перевіряти це дослідникам блоків та іншим аналітичним інструментам, зацікавленим у кількісній оцінці розподілу конкретних клієнтів у мережі. Будь ласка, зверніться до документації цього клієнта для отримання додаткової інформації про рядки версій. + +#### Запуск додаткових служб {#running-additional-services} + +Запуск власного вузла дозволяє використовувати послуги, які потребують прямого доступу до клієнта Ethereum RCP. Це служби, побудовані на основі Ethereum, як-от [рішення рівня 2](/developers/docs/scaling/#layer-2-scaling), бекенд для гаманців, оглядачі блоків, інструменти для розробників та інша інфраструктура Ethereum. + +#### Моніторинг вузла {#monitoring-the-node} + +Щоб належним чином контролювати свій вузол, подумайте про збір показників. Клієнти надають кінцеві точки метрики, щоб ви могли отримати всебічні дані про свій вузол. Використовуйте такі інструменти, як [InfluxDB](https://www.influxdata.com/get-influxdb/) або [Prometheus](https://prometheus.io/), щоб створювати бази даних, які ви можете перетворити на візуалізації та діаграми в програмному забезпеченні, як-от [Grafana](https://grafana.com/). Існує багато конфігурацій для використання цього програмного забезпечення та різних панелей Grafana для візуалізації вашого вузла та мережі в цілому. Наприклад, перегляньте [посібник з моніторингу Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/). + +У рамках моніторингу не забудьте слідкувати за продуктивністю ваших машин. Під час первинної синхронізації вашого вузла клієнтське програмне забезпечення може сильно завантажувати ЦП та оперативну пам’ять. На додаток до Grafana, ви можете використовувати інструменти, які пропонує ваша ОС, як-от `htop` або `uptime`, щоб зробити це. + +## Для подальшого читання {#further-reading} + +- [Посібники зі стейкінгу Ethereum](https://github.com/SomerEsat/ethereum-staking-guides) - _Сомер Есат, часто оновлюється_ +- [Посібник | Як налаштувати валідатор для стейкінгу Ethereum в основній мережі](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, часто оновлюється_ +- [Посібники ETHStaker із запуску валідаторів у тестових мережах](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, регулярно оновлюється_ +- [Приклад застосунку AWS Blockchain Node Runner для вузлів Ethereum](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) - _AWS, часто оновлюється_ +- [Поширені запитання про The Merge для операторів вузлів](https://notes.ethereum.org/@launchpad/node-faq-merge) - _липень 2022 р._ +- [Аналіз апаратних вимог для того, щоб бути повним валідованим вузлом Ethereum](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Альберт Палау, 24 вересня 2018 р._ +- [Запуск повних вузлів Ethereum: посібник для ледь мотивованих](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 7 листопада 2019 р._ +- [Розгортання вузла Hyperledger Besu в основній мережі Ethereum: переваги, вимоги та налаштування](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Феліпе Фараггі, 7 травня 2020 р._ +- [Розгортання клієнта Nethermind Ethereum зі стеком моніторингу](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 8 липня 2020 р._ + +## Пов'язані теми {#related-topics} + +- [Вузли та клієнти](/developers/docs/nodes-and-clients/) +- [Блоки](/developers/docs/blocks/) +- [Мережі](/developers/docs/networks/) diff --git a/public/content/translations/uk/developers/docs/oracles/index.md b/public/content/translations/uk/developers/docs/oracles/index.md new file mode 100644 index 00000000000..65347bbbde3 --- /dev/null +++ b/public/content/translations/uk/developers/docs/oracles/index.md @@ -0,0 +1,433 @@ +--- +title: "Оракули" +description: "Оракули надають смарт-контрактам Ethereum доступ до реальних даних, відкриваючи більше можливостей для використання та більшу цінність для користувачів." +lang: uk +--- + +Оракули — це програми, що створюють канали даних, які роблять джерела даних поза ланцюжком доступними для блокчейну для смарт-контрактів. Це необхідно, тому що смарт-контракти на базі Ethereum за замовчуванням не можуть отримати доступ до інформації, що зберігається за межами мережі блокчейн. + +Надання смарт-контрактам можливості виконуватись з використанням даних поза ланцюжком розширює корисність і цінність децентралізованих застосунків. Наприклад, ринки прогнозів у ланцюжку покладаються на оракулів, щоб надати інформацію про результати, які вони використовують для перевірки прогнозів користувачів. Припустимо, Аліса поставила 20 ETH на те, хто стане наступним президентом Сполучених Штатів. У цьому випадку ринку прогнозів dapp потрібен оракул, щоб підтвердити результати виборів і визначити, чи має Аліса право на виплату. + +## Передумови {#prerequisites} + +Ця сторінка розрахована на читача, знайомого з основами Ethereum, зокрема з [вузлами](/developers/docs/nodes-and-clients/), [механізмами досягнення консенсусу](/developers/docs/consensus-mechanisms/) та [EVM](/developers/docs/evm/). Ви також повинні добре розуміти [смарт-контракти](/developers/docs/smart-contracts/) й [анатомію смарт-контрактів](/developers/docs/smart-contracts/anatomy/), особливо [події](/glossary/#events). + +## Що таке блокчейн-оракул? {#what-is-a-blockchain-oracle} + +Оракули — це застосунки, які отримують, перевіряють і передають зовнішню інформацію (тобто інформацію, що зберігається поза ланцюжком) у смарт-контракти, що працюють на блокчейні. Окрім «витягування» даних поза ланцюжком і транслювання їх в Ethereum, оракули також можуть «передавати» інформацію з блокчейну до зовнішніх систем, наприклад, розблокувати смарт-замок, щойно користувач надішле плату через транзакцію Ethereum. + +Без оракула смарт-контракт був би повністю обмежений даними в ланцюжку. + +Оракули розрізняються за джерелом даних (одне або декілька джерел), моделями довіри (централізовані або децентралізовані) та архітектурою системи (негайне зчитування, публікація-підписка та запит-відповідь). Ми також можемо розрізняти оракулів залежно від того, чи отримують вони зовнішні дані для використання контрактами в ланцюжку (вхідні оракули), чи надсилають інформацію з блокчейну до застосунків поза ланцюжком (вихідні оракули), чи виконують обчислювальні завдання поза ланцюжком (обчислювальні оракули). + +## Навіщо смарт-контрактам оракули? {#why-do-smart-contracts-need-oracles} + +Багато розробників розглядають смарт-контракти як код, що виконується за певними адресами в блокчейні. Однак, більш [загальний погляд на смарт-контракти](/smart-contracts/) полягає в тому, що це самовиконувані програмні застосунки, здатні забезпечувати дотримання угод між сторонами після виконання певних умов, — звідси й термін «розумні контракти». + +Але використання смарт-контрактів для забезпечення виконання угод між людьми не є простим, враховуючи, що Ethereum є детермінованим. [Детермінована система](https://en.wikipedia.org/wiki/Deterministic_algorithm) — це система, яка завжди дає однакові результати за заданого початкового стану та певних вхідних даних, тобто в процесі обчислення вихідних даних із вхідних немає жодної випадковості чи варіації. + +Для досягнення детермінованого виконання блокчейни обмежують вузли в досягненні консенсусу щодо простих двійкових (істина/хиба) питань, використовуючи _лише_ дані, що зберігаються в самому блокчейні. Прикладами таких питань є: + +- "Чи підписував власник облікового запису (ідентифікований за допомогою відкритого ключа) цю транзакцію за допомогою парного закритого ключа?" +- "Чи достатньо коштів на цьому рахунку для проведення операції?" +- "Чи дійсна ця транзакція в контексті цього смарт-контракту?" тощо. + +Якби блокчейни отримували інформацію із зовнішніх джерел (тобто, з реального світу), детермінізм був би неможливий, що заважало б нодам домовлятися про дійсність змін стану блокчейну. Візьмемо для прикладу смарт-контракт, який виконує транзакцію на основі поточного курсу ETH-USD, отриманого з традиційного цінового API. Цей показник, імовірно, буде часто змінюватися (не кажучи вже про те, що API може застаріти або його можуть зламати), а це означає, що вузли, які виконують один і той самий код контракту, отримуватимуть різні результати. + +Для публічного блокчейну, як-от Ethereum, з тисячами вузлів по всьому світу, що обробляють транзакції, детермінізм має вирішальне значення. За відсутності центрального органу, що слугує джерелом істини, вузлам потрібні механізми для переходу в однаковий стан після застосування однакових транзакцій. Випадок, коли вузол А виконує код смарт-контракту і отримує в результаті "3", в той час як вузол Б отримує "7" після виконання тієї ж транзакції, призведе до порушення консенсусу і нівелює цінність Ethereum'у як децентралізованої обчислювальної платформи. + +Цей сценарій також підкреслює проблему, пов'язану з розробкою блокчейнів для отримання інформації із зовнішніх джерел. Однак оракули розв’язують цю проблему, отримуючи інформацію з джерел поза ланцюжком і зберігаючи її на блокчейні для використання смарт-контрактами. Оскільки інформація, що зберігається в ланцюжку, є незмінною та загальнодоступною, вузли Ethereum можуть безпечно використовувати імпортовані оракулом дані поза ланцюжком для обчислення змін стану без порушення консенсусу. + +Для цього оракул зазвичай складається зі смарт-контракту, що працює в ланцюжку, і деяких компонентів поза ланцюжком. Контракт у ланцюжку отримує запити на дані від інших смарт-контрактів, які він передає компоненту поза ланцюжком (що називається вузлом оракула). Ця нода оракула може запитувати джерела даних - наприклад, використовуючи інтерфейси прикладного програмування (API) - і відправляти транзакції для зберігання запитаних даних у сховищі смарт-контракту. + +По суті, блокчейн-оракул заповнює інформаційний розрив між блокчейном і зовнішнім середовищем, створюючи "гібридні смарт-контракти". Гібридний смарт-контракт — це контракт, який функціонує на основі поєднання коду контракту в ланцюжку та інфраструктури поза ланцюжком. Децентралізовані ринки прогнозів — чудовий приклад гібридних смарт-контрактів. Іншими прикладами можуть бути смарт-контракти зі страхування врожаю, які здійснюють виплати, коли група оракулів визначає, що відбулися певні погодні явища. + +## У чому проблема оракула? Проблема оракула {#the-oracle-problem} + +Оракули розв’язують важливу проблему, але також створюють певні ускладнення, наприклад: + +- Як перевірити, що вкинута інформація була отримана з правильного джерела або не була підроблена? + +- Як ми забезпечуємо постійну доступність цих даних та їх регулярне оновлення? + +Так звана "проблема оракула" демонструє проблеми, які виникають при використанні оракулів блокчейну для надсилання вхідних даних до смарт-контрактів. Дані від оракула мають бути правильними, щоб смарт-контракт виконувався правильно. Крім того, необхідність «довіряти» операторам оракулів у наданні точної інформації підриває аспект «відсутності довіри» у смарт-контрактах. + +Різні оракули пропонують різні розв’язання проблеми оракула, які ми розглянемо пізніше. Зазвичай оракулів оцінюють за тим, наскільки добре вони можуть впоратися з такими проблемами: + +1. **Правильність**: оракул не повинен змушувати смарт-контракти ініціювати зміни стану на основі недійсних даних поза ланцюжком. Оракул повинен гарантувати _автентичність_ і _цілісність_ даних. Автентичність означає, що дані були отримані з правильного джерела, тоді як цілісність означає, що дані залишилися недоторканими (тобто не були змінені), перш ніж їх було надіслано в ланцюжок. + +2. **Доступність**: оракул не повинен затримувати або перешкоджати смарт-контрактам виконувати дії та ініціювати зміни стану. Це означає, що дані від оракула мають бути _доступні за запитом_ без перерви. + +3. **Сумісність стимулів**: оракул повинен стимулювати постачальників даних поза ланцюжком надавати правильну інформацію смарт-контрактам. Сумісність стимулів передбачає _можливість атрибуції_ та _підзвітність_. Можливість атрибуції дає змогу пов’язати частину зовнішньої інформації з її постачальником, тоді як підзвітність пов’язує постачальників даних з інформацією, яку вони надають, щоб їх можна було винагородити або покарати залежно від якості наданої інформації. + +## Як працює сервіс блокчейн-оракул? Як працює сервіс блокчейн-оракулів? {#how-does-a-blockchain-oracle-service-work} + +### Користувачі {#users} + +Користувачі - це сутності (тобто смарт-контракти), які потребують інформації ззовні блокчейну для виконання певних дій. Основний робочий процес оракул-сервісу починається з того, що користувач надсилає запит на отримання даних до оракул-контракту. Запити на отримання даних, як правило, містять відповіді на деякі або всі з наведених нижче запитань: + +1. До яких джерел можуть звертатися вузли поза ланцюжком для отримання запитуваної інформації? + +2. Як журналісти обробляють інформацію з джерел даних та виокремлюють корисні дані? + +3. Скільки нод оракула може брати участь в отриманні даних? + +4. Як управляти розбіжностями у звітах оракулів? + +5. Який метод має бути реалізований при фільтрації подань та об'єднанні звітів в єдине значення? + +### Контракт оракула {#oracle-contract} + +Контракт оракула — це компонент сервісу оракула в ланцюжку. Він прослуховує запити даних від інших контрактів, ретранслює запити даних до вузлів оракула та транслює повернуті дані клієнтським контрактам. Цей контракт може також виконувати деякі обчислення над повернутими точками даних для отримання сукупного значення, яке буде надіслано до контракту-запитувача. + +Контракт оракула розкриває деякі функції, які клієнтські контракти викликають при запиті даних. Після отримання нового запиту смарт-контракт генерує [подію журналу](/developers/docs/smart-contracts/anatomy/#events-and-logs) з деталями запиту даних. Це сповіщає вузли поза ланцюжком, підписані на журнал (зазвичай за допомогою команди JSON-RPC `eth_subscribe`), які продовжують отримувати дані, визначені в події журналу. + +Нижче наведено [приклад контракту оракула](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) від Педро Кости. Це простий сервіс оракула, який може робити запити до API поза ланцюжком на вимогу інших смарт-контрактів і зберігати запитану інформацію в блокчейні: + +```solidity +pragma solidity >=0.4.21 <0.6.0; + +contract Oracle { + Request[] requests; //список запитів, зроблених до контракту + uint currentId = 0; //збільшення ідентифікатора запиту + uint minQuorum = 2; //мінімальна кількість відповідей, яку потрібно отримати, перш ніж оголосити остаточний результат + uint totalOracleCount = 3; //Жорстко закодована кількість оракулів + + // визначає загальний запит до API + struct Request { + uint id; //ідентифікатор запиту + string urlToQuery; //URL-адреса API + string attributeToFetch; //атрибут json (ключ), який потрібно отримати у відповіді + string agreedValue; //значення з ключа + mapping(uint => string) answers; //відповіді, надані оракулами + mapping(address => uint) quorum; //оракули, які запитуватимуть відповідь (1=оракул не проголосував, 2=оракул проголосував) + } + + //подія, яка запускає оракула за межами блокчейну + event NewRequest ( + uint id, + string urlToQuery, + string attributeToFetch + ); + + //спрацьовує, коли є консенсус щодо остаточного результату + event UpdatedRequest ( + uint id, + string urlToQuery, + string attributeToFetch, + string agreedValue + ); + + function createRequest ( + string memory _urlToQuery, + string memory _attributeToFetch + ) + public + { + uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); + Request storage r = requests[length-1]; + + // Жорстко закодовані адреси оракулів + r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; + r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; + r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; + + // запустити подію, яку має виявити оракул за межами блокчейну + emit NewRequest ( + currentId, + _urlToQuery, + _attributeToFetch + ); + + // збільшити ідентифікатор запиту + currentId++; + } + + //викликається оракулом для запису своєї відповіді + function updateRequest ( + uint _id, + string memory _valueRetrieved + ) public { + + Request storage currRequest = requests[_id]; + + //перевірити, чи є оракул у списку довірених оракулів + //і чи оракул ще не проголосував + if(currRequest.quorum[address(msg.sender)] == 1){ + + //позначка, що ця адреса проголосувала + currRequest.quorum[msg.sender] = 2; + + //перебір «масиву» відповідей, доки позиція не звільниться, і збереження отриманого значення + uint tmpI = 0; + bool found = false; + while(!found) { + //знайти перший порожній слот + if(bytes(currRequest.answers[tmpI]).length == 0){ + found = true; + currRequest.answers[tmpI] = _valueRetrieved; + } + tmpI++; + } + + uint currentQuorum = 0; + + //перебір списку оракулів і перевірка, чи достатньо оракулів (мінімальний кворум) + //проголосували за ту саму відповідь, що й поточна + for(uint i = 0; i < totalOracleCount; i++){ + bytes memory a = bytes(currRequest.answers[i]); + bytes memory b = bytes(_valueRetrieved); + + if(keccak256(a) == keccak256(b)){ + currentQuorum++; + if(currentQuorum >= minQuorum){ + currRequest.agreedValue = _valueRetrieved; + emit UpdatedRequest ( + currRequest.id, + currRequest.urlToQuery, + currRequest.attributeToFetch, + currRequest.agreedValue + ); + } + } + } + } + } +} +``` + +### Вузли оракула {#oracle-nodes} + +Вузол оракула є компонентом сервісу оракула поза ланцюжком. Він витягує інформацію із зовнішніх джерел, як-от API, розміщені на сторонніх серверах, і розміщує її в ланцюжку для використання смарт-контрактами. Вузли оракула прослуховують події від контракту оракула в ланцюжку та приступають до виконання завдання, описаного в журналі. + +Поширеним завданням для вузлів оракула є надсилання запиту [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) до служби API, аналіз відповіді для вилучення відповідних даних, форматування у вивід, що читається блокчейном, і надсилання його в ланцюжок шляхом включення в транзакцію до контракту оракула. Від вузла оракула також може знадобитися засвідчити достовірність і цілісність наданої інформації за допомогою "доказів автентичності", які ми розглянемо пізніше. + +Обчислювальні оракули також покладаються на вузли поза ланцюжком для виконання обчислювальних завдань, які було б непрактично виконувати в ланцюжку, враховуючи вартість газу та обмеження розміру блоку. Наприклад, вузлу оракула може бути доручено згенерувати достовірно випадкову цифру (наприклад, для ігор на основі блокчейну). + +## Патерни проєктування оракулів {#oracle-design-patterns} + +Оракули бувають різних типів, зокрема _негайного зчитування_, _публікації-підписки_ та _запиту-відповіді_, причому останні два є найпопулярнішими серед смарт-контрактів Ethereum. Тут ми коротко опишемо моделі публікації-підписки та запиту-відповіді. + +### Оракули публікації-підписки {#publish-subscribe-oracles} + +Цей тип оракула надає «канал даних», який інші контракти можуть регулярно читати для отримання інформації. У цьому випадку очікується, що дані часто змінюватимуться, тому клієнтські контракти повинні прослуховувати оновлення даних у сховищі оракула. Прикладом є оракул, який надає користувачам найновішу інформацію про ціну ETH-USD. + +### Оракули запиту-відповіді {#request-response-oracles} + +Налаштування запиту-відповіді дає змогу клієнтському контракту запитувати довільні дані, відмінні від тих, що надаються оракулом публікації-підписки. Оракули із запитом-відповіддю ідеально підходять, коли набір даних занадто великий для зберігання в сховищі смарт-контракту та/або користувачам у будь-який момент часу знадобиться лише невелика частина даних. + +Хоча оракули із запитом-відповіддю складніші за моделі публікації-підписки, вони по суті є тим, що ми описали в попередньому розділі. Оракул матиме компонент у ланцюжку, який отримує запит даних і передає його для обробки на вузол поза ланцюжком. + +Користувачі, які ініціюють запити даних, повинні покривати вартість отримання інформації з джерела поза ланцюжком. Клієнтський контракт також повинен надати кошти для покриття витрат на газ, понесених контрактом оракула під час повернення відповіді через функцію зворотного виклику, зазначену в запиті. + +## Централізовані та децентралізовані оракули {#types-of-oracles} + +### Централізовані оракули {#centralized-oracles} + +Централізований оракул контролюється єдиною організацією, відповідальною за агрегування інформації поза ланцюжком і оновлення даних контракту оракула за запитом. Централізовані оракули ефективні, оскільки покладаються на єдине джерело істини. Вони можуть краще функціонувати у випадках, коли власні набори даних публікуються безпосередньо власником із загальноприйнятим підписом. Однак вони мають і недоліки: + +#### Низькі гарантії правильності {#low-correctness-guarantees} + +З централізованими оракулами немає можливості підтвердити, чи правильна надана інформація, чи ні. Навіть «авторитетні» постачальники можуть стати шахраями або їх можуть зламати. Якщо оракул стає корумпованим, смарт-контракти будуть виконуватися на основі поганих даних. + +#### Низька доступність {#poor-availability} + +Централізовані оракули не гарантують, що дані поза ланцюжком завжди будуть доступні для інших смарт-контрактів. Якщо постачальник вирішить вимкнути послугу або хакер викраде компонент оракула поза ланцюжком, ваш смарт-контракт ризикує зазнати атаки типу «відмова в обслуговуванні» (DoS). + +#### Низька сумісність стимулів {#poor-incentive-compatibility} + +Централізовані оракули часто мають погано розроблені або взагалі відсутні стимули для постачальників даних надсилати точну/незмінну інформацію. Плата оракулу за правильність не гарантує чесності. Ця проблема стає серйознішою в міру збільшення вартості, контрольованої смарт-контрактами. + +### Децентралізовані оракули {#decentralized-oracles} + +Децентралізовані оракули призначені для подолання обмежень централізованих оракулів шляхом усунення окремих точок несправностей. Децентралізований сервіс оракулів складається з кількох учасників однорангової мережі, які формують консенсус щодо даних поза ланцюжком, перш ніж надсилати їх до смарт-контракту. + +Децентралізований оракул (в ідеалі) має бути бездозвільним, не вимагати довіри та вільним від адміністрування центральною стороною; насправді децентралізація серед оракулів — це спектр. Існують напівдецентралізовані мережі оракулів, у яких може брати участь будь-хто, але є «власник», який схвалює та видаляє вузли на основі попередньої продуктивності. Існують також повністю децентралізовані мережі оракулів: вони зазвичай працюють як автономні блокчейни і мають визначені механізми консенсусу для координації вузлів і покарання за неправомірну поведінку. + +Використання децентралізованих оракулів має наступні переваги: + +### Високі гарантії правильності {#high-correctness-guarantees} + +Децентралізовані оракули намагаються досягти коректності даних, використовуючи різні підходи. Це включає використання доказів, що засвідчують автентичність і цілісність повернутої інформації, і вимагає, щоб кілька суб’єктів колективно погодилися щодо дійсності даних поза ланцюжком. + +#### Докази автентичності {#authenticity-proofs} + +Докази автентичності - це криптографічні механізми, які дають можливість незалежної перевірки інформації, отриманої із зовнішніх джерел. Ці докази можуть підтвердити джерело інформації та виявити можливі зміни в даних після їх отримання. + +Приклади доказів автентичності включають: + +**Докази протоколу TLS**: вузли оракула часто отримують дані із зовнішніх джерел за допомогою безпечного HTTP-з’єднання на основі протоколу TLS (Transport Layer Security). Деякі децентралізовані оракули використовують докази автентичності для перевірки сеансів TLS (тобто підтвердження обміну інформацією між вузлом і певним сервером) і підтвердження того, що вміст сеансу не був змінений. + +**Атестації довіреного середовища виконання (TEE)**: [довірене середовище виконання](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) — це обчислювальне середовище в пісочниці, ізольоване від робочих процесів хост-системи. TEE гарантують, що будь-який прикладний код або дані, що зберігаються/використовуються в обчислювальному середовищі, зберігають цілісність, конфіденційність і незмінність. Користувачі також можуть генерувати атестацію, щоб довести, що екземпляр програми працює в довіреному середовищі виконання. + +Певні класи децентралізованих оракулів вимагають від операторів вузлів оракулів надавати атестації TEE. Це підтверджує користувачеві, що оператор вузла запускає екземпляр клієнта oracle у довіреному середовищі виконання. TEE не дозволяють зовнішнім процесам змінювати або зчитувати код і дані програми, отже, ці атестації доводять, що вузол оракула зберіг інформацію недоторканою і конфіденційною. + +#### Перевірка інформації на основі консенсусу {#consensus-based-validation-of-information} + +Централізовані оракули покладаються на єдине джерело достовірної інформації при наданні даних для смарт-контрактів, що створює можливість публікації недостовірної інформації. Децентралізовані оракули розв’язують цю проблему, покладаючись на кілька вузлів оракула для запиту інформації поза ланцюжком. Порівнюючи дані з кількох джерел, децентралізовані оракули зменшують ризик передачі недійсної інформації до контрактів у ланцюжку. + +Децентралізовані оракули, однак, повинні мати справу з розбіжностями в інформації, отриманій з декількох джерел поза ланцюжком. Щоб мінімізувати розбіжності в інформації та гарантувати, що дані, передані в оракул-контракт, відображають колективну думку вузлів оракула, децентралізовані оракули використовують наступні механізми: + +##### Голосування/оцінка точності даних + +Деякі децентралізовані мережі оракулів вимагають від учасників голосувати або робити ставки на точність відповідей на запити даних (наприклад, "Хто переміг на виборах у США в 2020 році?") використовуючи нативний токен мережі. Потім протокол агрегації об'єднує голоси та ставки і приймає відповідь, підтриману більшістю, як правильну. + +Вузли, відповіді яких відрізняються від відповіді більшості, караються тим, що їхні токени розподіляються між іншими вузлами, які надали більш правильні значення. Змушення вузлів надавати зобов'язання перед наданням даних стимулює чесні відповіді, оскільки вважається, що вони є раціональними економічними суб'єктами, які мають намір максимізувати прибутки. + +Стейкінг/голосування також захищає децентралізовані оракули від [атак Сивілли](/glossary/#sybil-attack), під час яких зловмисники створюють кілька ідентичностей, щоб обдурити систему консенсусу. Однак стейкінг не може запобігти "халяві" (коли вузли оракула копіюють інформацію від інших) та "лінивій перевірці" (коли вузли оракула слідують за більшістю, не перевіряючи інформацію самостійно). + +##### Механізми точки Шеллінга + +[Точка Шеллінга](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) — це концепція теорії ігор, яка припускає, що кілька об’єктів завжди будуть за замовчуванням приймати спільне розв’язання проблеми за відсутності будь-якого зв’язку. Механізми точок Шеллінга часто використовуються в децентралізованих мережах оракулів, щоб дозволити вузлам досягти консенсусу щодо відповідей на запити даних. + +Першою ідеєю для цього був [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), запропонований канал даних, де учасники надсилають відповіді на «скалярні» запитання (запитання, відповіді на які описуються величиною, наприклад, «яка ціна ETH?»), разом із депозитом. Користувачі, які надають значення між 25-м і 75-м [перцентилем](https://en.wikipedia.org/wiki/Percentile), отримують винагороду, а ті, чиї значення значно відхиляються від медіанного значення, караються. + +Хоча SchellingCoin сьогодні не існує, ряд децентралізованих оракулів, зокрема [оракули протоколу Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module), використовують механізм точки Шеллінга для підвищення точності даних оракула. Кожен Maker Oracle складається з P2P-мережі вузлів поза ланцюжком («ретрансляторів» і «фідів»), які подають ринкові ціни на заставні активи, і контракту «Medianizer» в ланцюжку, який обчислює медіану всіх наданих значень. Після закінчення зазначеного періоду затримки це медіанне значення стає новою базовою ціною для відповідного активу. + +Інші приклади оракулів, які використовують механізми точки Шеллінга, включають [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) і [Witnet](https://witnet.io/). В обох системах відповіді від вузлів оракула в одноранговій мережі зводяться в єдине загальне значення, наприклад, середнє або медіану. Вузли заохочуються або караються відповідно до того, наскільки їхні відповіді збігаються або відхиляються від загального значення. + +Механізми точки Шеллінга привабливі, тому що вони мінімізують вплив на ланцюжок (потрібно надіслати лише одну транзакцію), гарантуючи при цьому децентралізацію. Останнє можливе тому, що вузли повинні підписати список надісланих відповідей перед тим, як він потрапить до алгоритму, який обчислює середнє/медіанне значення. + +### Доступність {#availability} + +Децентралізовані сервіси оракулів забезпечують високу доступність даних поза ланцюжком для смарт-контрактів. Це досягається шляхом децентралізації як джерела інформації поза ланцюжком, так і вузлів, відповідальних за передачу інформації в ланцюжок. + +Це забезпечує відмовостійкість, оскільки контракт oracle може покладатися на декілька вузлів (які також покладаються на декілька джерел даних) для виконання запитів з інших контрактів. Децентралізація на рівні джерела _та_ оператора вузла має вирішальне значення — мережа вузлів оракула, що обслуговують інформацію, отриману з того самого джерела, зіткнеться з тією ж проблемою, що й централізований оракул. + +Оракули на основі стейкінгу також можуть штрафувати операторів вузлів, які не можуть швидко відповідати на запити даних. Це значно стимулює вузли оракула інвестувати у відмовостійку інфраструктуру та надавати дані вчасно. + +### Хороша сумісність стимулів {#good-incentive-compatibility} + +Децентралізовані оракули реалізують різні схеми стимулювання, щоб запобігти [візантійській](https://en.wikipedia.org/wiki/Byzantine_fault) поведінці серед вузлів оракулів. Зокрема, вони досягають _можливості атрибуції_ та _підзвітності_: + +1. Децентралізовані вузли оракула часто повинні підписувати дані, які вони надають у відповідь на запити даних. Ця інформація допомагає оцінити історичну продуктивність вузлів оракула, щоб користувачі могли відфільтрувати ненадійні вузли оракула під час запитів даних. Прикладом є [алгоритмічна система репутації](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) Witnet. + +2. Децентралізовані оракули - як пояснювалося раніше - можуть вимагати від вузлів зробити ставку на їхню впевненість у правдивості даних, які вони надають. Якщо претензія підтверджується, ця частка може бути повернута разом із винагородою за чесне обслуговування. Але її також можна скоротити, якщо інформація невірна, що забезпечує певний рівень підзвітності. + +## Застосування оракулів у смарт-контрактах {#applications-of-oracles-in-smart-contracts} + +Нижче наведено поширені випадки використання оракулів в Ethereum: + +### Отримання фінансових даних {#retrieving-financial-data} + +Застосунки [децентралізованих фінансів](/defi/) (DeFi) дають змогу однорангове кредитування, запозичення та торгівлю активами. Це часто вимагає отримання різної фінансової інформації, зокрема даних про обмінний курс (для розрахунку фіатної вартості криптовалют або порівняння цін токенів) і даних ринків капіталу (для розрахунку вартості токенізованих активів, як-от золото або долар США). + +Протокол кредитування DeFi, наприклад, повинен запитувати поточні ринкові ціни на активи (наприклад, ETH), що внесені як застава. Це дає змогу контракту визначити вартість заставних активів і визначити, скільки можна запозичити в системі. + +Популярні «цінові оракули» (як їх часто називають) у DeFi включають цінові канали Chainlink, [Open Price Feed](https://compound.finance/docs/prices) від Compound Protocol, [середньозважені за часом ціни (TWAP)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) від Uniswap і [оракули Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module). + +Розробники повинні розуміти застереження, пов'язані з цими ціновими оракулами, перш ніж інтегрувати їх у свій проєкт. Ця [стаття](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) містить детальний аналіз того, що слід враховувати, плануючи використовувати будь-який із згаданих цінових оракулів. + +Нижче наведено приклад того, як ви можете отримати останню ціну ETH у вашому смарт-контракті за допомогою цінового каналу Chainlink: + +```solidity +pragma solidity ^0.6.7; + +import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; + +contract PriceConsumerV3 { + + AggregatorV3Interface internal priceFeed; + + /** + * Network: Kovan + * Aggregator: ETH/USD + * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331 + */ + constructor() public { + priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); + } + + /** + * Returns the latest price + */ + function getLatestPrice() public view returns (int) { + ( + uint80 roundID, + int price, + uint startedAt, + uint timeStamp, + uint80 answeredInRound + ) = priceFeed.latestRoundData(); + return price; + } +} +``` + +### Генерування перевірної випадковості {#generating-verifiable-randomness} + +Деякі блокчейн-застосунки, як-от ігри на основі блокчейну або лотерейні схеми, вимагають високого рівня непередбачуваності та випадковості для ефективної роботи. Однак детерміноване виконання блокчейнів усуває випадковість. + +Початковий підхід полягав у використанні псевдовипадкових криптографічних функцій, як-от `blockhash`, але ними могли [маніпулювати майнери](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) розв’язуючи алгоритм доказу роботи. Крім того, [перехід Ethereum на доказ частки володіння](/roadmap/merge/) означає, що розробники більше не можуть покладатися на `blockhash` для випадковості в ланцюжку. Натомість [механізм RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) Beacon Chain надає альтернативне джерело випадковості. + +Можна згенерувати випадкове значення поза ланцюжком і надіслати його в ланцюжок, але це накладає високі вимоги до довіри з боку користувачів. Вони повинні вірити, що значення було справді згенеровано за допомогою непередбачуваних механізмів і не було змінено під час передачі. + +Оракули, розроблені для обчислень поза ланцюжком, розв’язують цю проблему, безпечно генеруючи випадкові результати поза ланцюжком, які вони транслюють у ланцюжок разом із криптографічними доказами, що засвідчують непередбачуваність процесу. Прикладом є [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (перевірна випадкова функція), яка є доказово чесним і захищеним від несанкціонованого доступу генератором випадкових чисел (RNG), корисним для створення надійних смарт-контрактів для застосунків, які покладаються на непередбачувані результати. + +### Отримання результатів подій {#getting-outcomes-for-events} + +З оракулами легко створювати смарт-контракти, які реагують на події реального світу. Сервіси оракулів уможливлюють це, дозволяючи контрактам підключатися до зовнішніх API через компоненти поза ланцюжком і споживати інформацію з цих джерел даних. Наприклад, згаданий раніше децентралізований застосунок для прогнозування може надіслати запит оракулу на повернення результатів виборів із надійного джерела поза ланцюжком (наприклад, Associated Press). + +Використання оракулів для отримання даних на основі реальних результатів дає змогу використовувати інші нові варіанти; наприклад, для ефективної роботи децентралізованого страхового продукту потрібна точна інформація про погоду, стихійні лиха тощо. + +### Автоматизація смарт-контрактів {#automating-smart-contracts} + +Смарт-контракти не запускаються автоматично; радше зовнішній обліковий запис (EOA) або інший обліковий запис контракту повинен викликати відповідні функції для виконання коду контракту. У більшості випадків основна частина функцій контракту є загальнодоступною і може бути викликана EOA та іншими контрактами. + +Але в контракті також є _приватні функції_, недоступні для інших; але які є критично важливими для загальної функціональності децентралізованого застосунку. Приклади включають функцію `mintERC721Token()`, яка періодично випускає нові NFT для користувачів, функцію для присудження виплат на ринку прогнозів або функцію для розблокування токенів у стейкінгу на DEX. + +Розробникам доведеться періодично запускати такі функції, щоб забезпечити безперебійну роботу застосунку. Однак це може призвести до того, що розробники втрачатимуть більше годин на рутинні завдання, тому автоматизація виконання смарт-контрактів є привабливою. + +Деякі децентралізовані мережі оракулів пропонують послуги автоматизації, які дають змогу вузлам оракулів поза ланцюжком запускати функції смарт-контрактів відповідно до параметрів, визначених користувачем. Зазвичай для цього потрібно «зареєструвати» цільовий контракт у службі оракула, надати кошти для оплати оператору оракула та вказати умови або час для запуску контракту. + +Мережа [Keeper Network](https://chain.link/keepers) від Chainlink надає можливості для смарт-контрактів передавати на аутсорсинг регулярні завдання з технічного обслуговування в мінімізований за довірою та децентралізований спосіб. Прочитайте офіційну [документацію Keeper's](https://docs.chain.link/docs/chainlink-keepers/introduction/), щоб отримати інформацію про те, як зробити ваш контракт сумісним з Keeper і використовувати службу Upkeep. + +## Як використовувати блокчейн-оракули {#use-blockchain-oracles} + +Існує кілька застосунків-оракулів, які ви можете інтегрувати у свій децентралізований застосунок Ethereum: + +**[Chainlink](https://chain.link/)** - _Децентралізовані мережі оракулів Chainlink забезпечують захищені від несанкціонованого доступу вхідні дані, вихідні дані та обчислення для підтримки розширених смарт-контрактів на будь-якому блокчейні._ + +**[RedStone Oracles](https://redstone.finance/)** - _RedStone — це децентралізований модульний оракул, який надає оптимізовані за газом канали даних. Він спеціалізується на пропонуванні цінових каналів для нових активів, як-от токени ліквідного стейкінгу (LST), токени ліквідного рестейкінгу (LRT) і похідні інструменти стейкінгу Bitcoin._ + +**[Chronicle](https://chroniclelabs.org/)** - _Chronicle долає поточні обмеження передачі даних у ланцюжку, розробляючи справді масштабовані, економічно ефективні, децентралізовані та перевірні оракули._ + +**[Witnet](https://witnet.io/)** - _Witnet — це бездозвільний, децентралізований і стійкий до цензури оракул, що допомагає смарт-контрактам реагувати на реальні події з сильними крипто-економічними гарантіями._ + +**[UMA Oracle](https://uma.xyz)** - _Оптимістичний оракул UMA дає змогу смарт-контрактам швидко отримувати будь-які дані для різних застосунків, зокрема страхування, фінансових деривативів і ринків прогнозів._ + +**[Tellor](https://tellor.io/)** - _Tellor — це прозорий і бездозвільний протокол оракула, за допомогою якого ваш смарт-контракт може легко отримати будь-які дані, коли вони йому потрібні._ + +**[Band Protocol](https://bandprotocol.com/)** - _Band Protocol — це міжланцюгова платформа оракула даних, яка агрегує та підключає реальні дані та API до смарт-контрактів._ + +**[Pyth Network](https://pyth.network/)** - _Мережа Pyth — це першостороння фінансова мережа оракулів, призначена для публікації безперервних реальних даних у ланцюжку в захищеному від несанкціонованого доступу, децентралізованому та самодостатньому середовищі._ + +**[API3 DAO](https://www.api3.org/)** - _API3 DAO надає першосторонні рішення оракулів, які забезпечують більшу прозорість джерел, безпеку та масштабованість у децентралізованому рішенні для смарт-контрактів_ + +**[Supra](https://supra.com/)** - вертикально інтегрований набір інструментів для міжланцюгових рішень, які об’єднують усі блокчейни, публічні (L1 та L2) або приватні (підприємства), надаючи децентралізовані цінові канали оракулів, які можна використовувати для випадків у ланцюжку та поза ланцюжком. + +**[Gas Network](https://gas.network/)** - розподілена платформа оракулів, що надає дані про ціни на газ у реальному часі в блокчейні. Переносячи дані від провідних постачальників даних про ціни на газ у ланцюжок, Gas Network допомагає забезпечити сумісність. Gas Network підтримує дані для понад 35 ланцюжків, включно з основною мережею Ethereum і багатьма провідними L2. + +## Для подальшого читання {#further-reading} + +**Статті** + +- [Що таке блокчейн-оракул?](https://chain.link/education/blockchain-oracles) — _Chainlink_ +- [Що таке блокчейн-оракул?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Патрік Коллінз_ +- [Децентралізовані оракули: вичерпний огляд](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Жульєн Тевенар_ +- [Реалізація блокчейн-оракула на Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Педро Коста_ +- [Чому смарт-контракти не можуть здійснювати виклики API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ +- [Отже, ви хочете використовувати ціновий оракул](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ + +**Відео** + +- [Оракули та розширення корисності блокчейну](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ + +**Посібники** + +- [Як отримати поточну ціну Ethereum у Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ +- [Споживання даних оракула](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ + +**Приклади проектів** + +- [Повний стартовий проєкт Chainlink для Ethereum на Solidity](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ diff --git a/public/content/translations/uk/developers/docs/programming-languages/dart/index.md b/public/content/translations/uk/developers/docs/programming-languages/dart/index.md new file mode 100644 index 00000000000..31c8b3daa2e --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/dart/index.md @@ -0,0 +1,32 @@ +--- +title: "Ethereum для розробників Dart" +description: "Дізнайся, як розвивати Ethereum, використовуючи мову Dart" +lang: uk +incomplete: true +--- + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +## Навчальні посібники {#tutorials} + +- [Flutter і блокчейн – Dapp «Привіт, світе!»](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) проведе вас через усі етапи для початку роботи: + 1. Написання смарт-контракту на [Solidity](https://soliditylang.org/) + 2. Написання інтерфейсу користувача в Дарті +- [Створення мобільного dApp за допомогою Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) набагато коротший, що може бути краще, + якщо ви вже знаєте основи +- Якщо ви віддаєте перевагу навчанню, переглядаючи відео, можете подивитися [Створіть свій перший блокчейн-додаток на Flutter](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), яке триває близько години +- Якщо ви нетерплячі, вам може більше сподобатися [Створення децентралізованого блокчейн-додатка за допомогою Flutter і Dart на Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), що триває лише близько двадцяти хвилин +- [Інтеграція MetaMask у застосунок Flutter за допомогою Web3Modal від WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) — це коротке відео проведе вас через етапи інтеграції MetaMask у ваші застосунки Flutter за допомогою бібліотеки [Web3Modal](https://pub.dev/packages/web3modal_flutter) від WalletConnect +- [Курс для розробників мобільних блокчейн-додатків із Solidity та Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) — плейліст курсу для фулстек-розробника мобільних блокчейн-додатків + +## Робота з клієнтами Ethereum {#working-with-ethereum-clients} + +Ви можете використовувати Ethereum для створення децентралізованих додатків (або "dapps"), які використовують переваги криптовалюти та технології блокчейну. +Існує принаймні дві бібліотеки для Dart, що наразі підтримуються, для використання +[JSON-RPC API](/developers/docs/apis/json-rpc/) для Ethereum. + +1. [Web3dart від pwa.ir](https://pub.dev/packages/web3dart) +2. [Ethereum 5.0.0 від darticulate.com](https://pub.dev/packages/ethereum) + +Також існують додаткові бібліотеки, які дають змогу маніпулювати конкретними адресами Ethereum або отримувати ціни на різні криптовалюти. +[Повний список можна переглянути тут](https://pub.dev/dart/packages?q=ethereum). diff --git a/public/content/translations/uk/developers/docs/programming-languages/delphi/index.md b/public/content/translations/uk/developers/docs/programming-languages/delphi/index.md new file mode 100644 index 00000000000..6bb01996a8d --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/delphi/index.md @@ -0,0 +1,56 @@ +--- +title: "Ethereum для розробників мовою Delphi" +description: "Дізнайсь, як покращувати Ethereum за допомогою мови програмування Delphi" +lang: uk +incomplete: true +--- + + + +Дізнайсь, як покращувати Ethereum за допомогою мови програмування Delphi + + + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Вони можуть контролювати цифрові активи, щоб створювати нові види фінансових програм. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +Створюйте децентралізовані програми поверх Ethereum і взаємодійте зі смарт-контрактами за допомогою мови програмування Delphi! + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Почніть інтегрувати Delphi з Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Довідкові матеріали та посилання для початківців {#beginner-references-and-links} + +**Про бібліотеку Delphereum** + +- [Що таке Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md) +- [Підключення Delphi до локального блокчейну (в оперативній пам'яті)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Підключення Delphi до головної мережі Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [Підключення Delphi до смарт-контрактів](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) + +**Хочете пропустити налаштування і відразу перейти до прикладів?** + +- [Смарт-контракт і Delphi за 3 хвилини — частина 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [Смарт-контракт і Delphi за 3 хвилини — частина 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) + +## Статті для середнього рівня {#intermediate-articles} + +- [Створення підпису повідомлення, підписаного Ethereum, у Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [Переказ ефіру за допомогою Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [Переказ токенів ERC-20 за допомогою Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Delphi та Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [QuikNode, Ethereum і Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) +- [Delphi й темний ліс Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Обмін одного токена на інший у Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers](/developers/). diff --git a/public/content/translations/uk/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/uk/developers/docs/programming-languages/dot-net/index.md new file mode 100644 index 00000000000..336e8585a22 --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/dot-net/index.md @@ -0,0 +1,86 @@ +--- +title: "Ethereum для розробників мовою .NET" +description: "Дізнайтесь, як покращувати Ethereum за допомогою проектів та інструментів на основі .NET" +lang: uk +incomplete: true +--- + +Дізнайтеся, як розробляти для Ethereum, використовуючи проєкти та інструменти на основі .NET + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Вони можуть контролювати цифрові активи, щоб створювати нові види фінансових програм. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +Створюйте децентралізовані програми поверх Ethereum і взаємодійте зі смарт-контрактами за допомогою інструментів і мов зі стека технологій Microsoft із підтримкою C#, #Visual Basic .NET, F#, використовуючи такі засоби, як VSCode та Visual Studio, на платформах .NET Framework/.NET Core/.NET Standard. Розгорніть блокчейн Ethereum на Azure за допомогою Microsoft Azure Blockchain за лічені хвилини. Перенесіть своє захоплення .NET на Ethereum! + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Зробіть свої перші кроки до інтеграції .NET із Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Довідкові матеріали та посилання для початківців {#beginner-references-and-links} + +**Введення в бібліотеку Nethereum і VS Code Solidity** + +- [Nethereum, початок роботи](https://docs.nethereum.com/en/latest/getting-started/) +- [Встановлення VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [Робочий процес розробника .NET для створення та виклику смарт-контрактів Ethereum](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Інтеграція смарт-контрактів з Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Взаємодія .NET і смарт-контрактів блокчейну Ethereum за допомогою Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), також [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) +- [Nethereum — бібліотека інтеграції .NET з відкритим вихідним кодом для блокчейну](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Запис транзакцій Ethereum до бази даних SQL за допомогою Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [Дізнайтеся, як легко розгортати смарт-контракти Ethereum за допомогою C# та VisualStudio](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**Хочете пропустити налаштування і відразу перейти до прикладів?** + +- [Playground](http://playground.nethereum.com/) — взаємодійте з Ethereum і дізнавайтеся, як використовувати Nethereum через браузер. + - Запит балансу облікового запису [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - Запит балансу смарт-контракту ERC20 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - Переказ Ether на обліковий запис [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) + - ... Та багато іншого! + +## Статті для середнього рівня {#intermediate-articles} + +- [Nethereum Workbook/Список зразків](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [Розгорніть власні тестові мережі для розробки](https://github.com/Nethereum/Testchains) +- [Плагін Codegen для VSCode для Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity та Ethereum: чому й як](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [Створення веб-API ASP.NET Core для dapp-застосунків Ethereum](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [Використання Nethereum Web3 для реалізації системи відстеження ланцюга постачання](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Обробка блоків Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), із [зразком C# Playground](http://playground.nethereum.com/csharp/id/1025) +- [Потокова передача даних Nethereum через Websocket](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Kaleido та Nethereum](https://kaleido.io/kaleido-and-nethereum/) +- [Quorum та Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Azure Key Vault та Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) +- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) +- [Еталонна архітектура серверної частини Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) + +## Проєкти, інструменти та інші цікаві речі .NET {#dot-net-projects-tools-and-other-fun-stuff} + +- [Nethereum Playground](http://playground.nethereum.com/) — _компілюйте, створюйте та запускайте фрагменти коду Nethereum у браузері_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) — _кодогенератор Nethereum з інтерфейсом користувача в Blazor_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) — _легкий оглядач блокчейнів .NET Wasm SPA і простий гаманець_ +- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) — _механізм бізнес-правил (і для платформи .NET, і для платформи Ethereum), що за своєю суттю керується метаданими_ +- [Nethermind](https://github.com/NethermindEth/nethermind) — _клієнт Ethereum на .NET Core для Linux, Windows, MacOS_ +- [eth-utils](https://github.com/ethereum/eth-utils/) — _службові функції для роботи з кодовими базами, пов'язаними з Ethereum_ +- [TestChains](https://github.com/Nethereum/TestChains) — _попередньо налаштовані тестові ланцюжки .NET для швидкого реагування (PoA)_ + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers](/developers/). + +## Учасники спільноти .NET {#dot-net-community-contributors} + +У Nethereum ми здебільшого спілкуємося в [Gitter](https://gitter.im/Nethereum/Nethereum), де кожен може ставити запитання, відповідати на них, отримувати допомогу або просто відпочивати. Не соромтеся створювати PR або issue в [репозиторії Nethereum на GitHub](https://github.com/Nethereum) або просто перегляньте безліч побічних/зразкових проєктів, які ми маємо. Ви також можете знайти нас у [Discord](https://discord.gg/jQPrR58FxX)! + +Якщо ви новачок у Nethermind і вам потрібна допомога, щоб почати, приєднуйтеся до нашого [Discord](http://discord.gg/PaCMRFdvWT). Наші розробники готові відповісти на ваші запитання. Не соромтеся створювати PR або повідомляти про будь-які проблеми в [репозиторії Nethermind на GitHub](https://github.com/NethermindEth/nethermind). + +## Інші зведені списки {#other-aggregated-lists} + +[Офіційний сайт Nethereum](https://nethereum.com/) +[Офіційний сайт Nethermind](https://nethermind.io/) diff --git a/public/content/translations/uk/developers/docs/programming-languages/elixir/index.md b/public/content/translations/uk/developers/docs/programming-languages/elixir/index.md new file mode 100644 index 00000000000..fd326825f29 --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/elixir/index.md @@ -0,0 +1,55 @@ +--- +title: "Ethereum для розробників Elixir" +description: "Дізнайтеся, як розробляти для Ethereum, використовуючи проєкти та інструменти на базі Elixir." +lang: uk +incomplete: false +--- + +Дізнайтеся, як розробляти для Ethereum, використовуючи проєкти та інструменти на базі Elixir. + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть не вимагати довіри, а це означає, що після їх розгортання в Ethereum вони завжди працюватимуть так, як запрограмовано. Вони можуть контролювати цифрові активи для створення нових видів фінансових додатків. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть свої перші кроки до інтеграції Elixir з Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статті для початківців {#beginner-articles} + +- [Нарешті розбираємося з обліковими записами Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers — першокласна Web3-бібліотека Ethereum для Elixir](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## Статті для середнього рівня {#intermediate-articles} + +- [Як підписувати необроблені транзакції контрактів Ethereum за допомогою Elixir](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [Смарт-контракти Ethereum та Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Проєкти та інструменти Elixir {#elixir-projects-and-tools} + +### Активні {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) — _реалізація BIP32 та BIP44 у Elixir (багатоакаунтна ієрархія для детермінованих гаманців)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) — _клієнт JSON-RPC для блокчейну Ethereum на Elixir_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) — _комплексна Web3-бібліотека для взаємодії зі смарт-контрактами в Ethereum за допомогою Elixir_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) — _бібліотека для підпису KMS для Ethers (підписання транзакцій за допомогою AWS KMS)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) — _реалізація парсера/декодера/кодера Ethereum ABI на Elixir_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) — _бібліотека Elixir для обчислення хешів Keccak SHA3-256 з використанням NIF, створеного з крейту tiny-keccak на Rust_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) — _реалізація на Elixir кодування RLP (Recursive Length Prefix) від Ethereum_ + +### Заархівовано / Більше не підтримується {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) — _утиліти Ethereum для Elixir_ +- [exw3](https://github.com/hswick/exw3) — _високорівневий клієнт Ethereum RPC для Elixir_ +- [mana](https://github.com/mana-ethereum/mana) — _реалізація повного вузла Ethereum, написана на Elixir_ + +Шукаєте більше ресурсів? Перегляньте нашу [сторінку для розробників](/developers/). + +## Учасники спільноти Elixir {#elixir-community-contributors} + +[Канал #ethereum у Slack спільноти Elixir](https://elixir-lang.slack.com/archives/C5RPZ3RJL) об’єднує спільноту, що швидко зростає, і є спеціалізованим ресурсом для обговорення будь-якого з вищезазначених проєктів і пов’язаних тем. diff --git a/public/content/translations/uk/developers/docs/programming-languages/golang/index.md b/public/content/translations/uk/developers/docs/programming-languages/golang/index.md new file mode 100644 index 00000000000..f71cacc516e --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/golang/index.md @@ -0,0 +1,84 @@ +--- +title: "Ethereum для розробників мовою Go" +description: "Дізнайтеся, як розробляти програми для Ethereum за допомогою проектів та інструментів на основі Go" +lang: uk +incomplete: true +--- + +Дізнайтеся, як розробляти для Ethereum за допомогою проєктів та інструментів на основі Go + +Використовуйте Ethereum для створення децентралізованих додатків. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Це програми, які можуть без перешкод запускатися в мережі P2P. Їх не контролюють організації або фізичні особи. Їх також майже неможливо піддати цензурі. Вони можуть контролювати цифрові об’єкти для створення нових типів програм. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть свої перші кроки до інтеграції Go з Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Посібник з контрактів](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) + +## Статті та книги для початківців {#beginner-articles-and-books} + +- [Початок роботи з Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) +- [Використання Golang для підключення до Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Розгортання смарт-контрактів Ethereum за допомогою Golang](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Покроковий посібник із тестування та розгортання смарт-контрактів Ethereum на Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [Електронна книга: Розробка для Ethereum на Go](https://goethereumbook.org/) - _Розробка застосунків Ethereum на Go_ + +## Статті та документи для середнього рівня {#intermediate-articles-and-docs} + +- [Документація Go Ethereum](https://geth.ethereum.org/docs/) - _Офіційна документація Ethereum для Golang_ +- [Посібник програміста Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _Ілюстрований посібник, що включає дерево станів, мультидокази та обробку транзакцій_ +- [Erigon та Ethereum без стану](https://youtu.be/3-Mn7OckSus?t=394) - _Конференція спільноти Ethereum 2020 (EthCC 3)_ +- [Erigon: оптимізація клієнтів Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _Devcon 4, 2018_ +- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [Створення dapp на Go за допомогою Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [Робота з приватною мережею Ethereum за допомогою Golang та Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Модульне тестування контрактів Solidity на Ethereum за допомогою Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Короткий довідник із використання Geth як бібліотеки](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Симульований бекенд GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [Застосунки «Блокчейн як послуга» з використанням Ethereum та Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [Розподілені сховища IPFS та Swarm у блокчейн-застосунках Ethereum](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [Мобільні клієнти: бібліотеки та внутрішньопроцесні вузли Ethereum](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [Нативні dapps: прив’язки Go до контрактів Ethereum](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) + +## Проєкти та інструменти на Go {#go-projects-and-tools} + +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Офіційна реалізація протоколу Ethereum на Go_ +- [Аналіз коду Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Огляд та аналіз вихідного коду Go Ethereum_ +- [Erigon](https://github.com/ledgerwatch/erigon) - _Швидша похідна версія Go Ethereum, що орієнтована на архівні вузли_ +- [Golem](https://github.com/golemfactory/golem) - _Golem створює глобальний ринок обчислювальних потужностей_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _Реалізація Ethereum із керованим доступом, що підтримує конфіденційність даних_ +- [Prysm](https://github.com/prysmaticlabs/prysm) - _Реалізація Ethereum «Serenity» 2.0 на Go_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _Децентралізований Twitter: сервіс мікроблогів, що працює на блокчейні Ethereum_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Реалізація на Golang і розширення специфікації Minimum Viable Plasma_ +- [Відкритий майнінг-пул Ethereum](https://github.com/sammy007/open-ethereum-pool) - _Майнінг-пул Ethereum з відкритим кодом_ +- [HD-гаманець Ethereum](https://github.com/miguelmota/go-ethereum-hdwallet) - _Похідні HD-гаманця Ethereum на Go_ +- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Підтримка багатьох різновидів мереж Ethereum_ +- [Полегшений клієнт Geth](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Реалізація Geth для полегшеного субпротоколу Ethereum_ +- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _Проста реалізація гаманця Ethereum та утиліти на Golang_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _Ефективний доступ до даних блокчейну через Go SDK для понад 200 блокчейнів_ + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers](/developers/) + +## Учасники спільноти Go {#go-community-contributors} + +- [Discord-сервер Geth](https://discordapp.com/invite/nthXNEv) +- [Geth Gitter](https://gitter.im/ethereum/go-ethereum) +- [Gophers Slack](https://invite.slack.golangbridge.org/) - [канал #ethereum](https://gophers.slack.com/messages/C9HP1S9V2) +- [StackExchange - Ethereum](https://ethereum.stackexchange.com/) +- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth) +- [Ethereum Gitter](https://gitter.im/ethereum/home) +- [Geth light Client Gitter](https://gitter.im/ethereum/light-client) + +## Інші зведені списки {#other-aggregated-lists} + +- [Чудовий Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: повний список інструментів для розробників Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Джерело на GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/uk/developers/docs/programming-languages/index.md b/public/content/translations/uk/developers/docs/programming-languages/index.md new file mode 100644 index 00000000000..d95a2bea37d --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/index.md @@ -0,0 +1,32 @@ +--- +title: "Мови програмування" +description: "Знайдіть ресурси для розробки на Ethereum для різних мов програмування, зокрема JavaScript, Python, Go, Rust тощо." +lang: uk +--- + +Поширеною помилкою є думка, що для розробки на Ethereum розробники мають писати [смарт-контракти](/developers/docs/smart-contracts/). Це неправда. +Однією з переваг мережі та спільноти Ethereum є те, що ви можете [брати участь](/community/) практично будь-якою мовою програмування. + +Ethereum та його спільнота підтримують відкритий вихідний код. Ви можете переглянути проекти спільноти (зокрема, налаштування клієнтів, API, фреймворки розробки, інструменти для тестування) різними мовами. + +## Оберіть мову {#data} + +Виберіть мову програмування, щоб знайти проекти, ресурси та віртуальні спільноти: + +- [Ethereum для розробників на Dart](/developers/docs/programming-languages/dart/) +- [Ethereum для розробників на Delphi](/developers/docs/programming-languages/delphi/) +- [Ethereum для розробників на .NET](/developers/docs/programming-languages/dot-net/) +- [Ethereum для розробників на Elixir](/developers/docs/programming-languages/elixir/) +- [Ethereum для розробників на Go](/developers/docs/programming-languages/golang/) +- [Ethereum для розробників на Java](/developers/docs/programming-languages/java/) +- [Ethereum для розробників на JavaScript](/developers/docs/programming-languages/javascript/) +- [Ethereum для розробників на Python](/developers/docs/programming-languages/python/) +- [Ethereum для розробників на Ruby](/developers/docs/programming-languages/ruby/) +- [Ethereum для розробників на Rust](/developers/docs/programming-languages/rust/) + +### Що робити, якщо моя мова не підтримується {#other-lang} + +Якщо ви хочете додати посилання на ресурси або вказати на віртуальну спільноту для додаткової мови програмування, ви можете надіслати запит на створення нової сторінки, [відкривши issue](https://github.com/ethereum/ethereum-org-website/issues/new/choose). + +Якщо ви просто хочете написати код для взаємодії з блокчейном за допомогою мови, яка наразі не підтримується, +ви можете використовувати [інтерфейс JSON-RPC](/developers/docs/apis/json-rpc/) для підключення до мережі Ethereum. Будь-яка мова програмування, яка використовує TCP/IP може користуватися цим інтерфейсом. diff --git a/public/content/translations/uk/developers/docs/programming-languages/java/index.md b/public/content/translations/uk/developers/docs/programming-languages/java/index.md new file mode 100644 index 00000000000..48234516e5e --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/java/index.md @@ -0,0 +1,64 @@ +--- +title: "Ethereum для розробників мовою Java" +description: "Дізнайтеся, як розробляти для Ethereum за допомогою проектів та інструментів на основі Java" +lang: uk +incomplete: true +--- + +Дізнайтеся, як розробляти для Ethereum за допомогою проектів та інструментів на основі Java + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Вони можуть контролювати цифрові активи, щоб створювати нові види фінансових програм. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть свої перші кроки до інтеграції Java з Ethereum** + +Потрібен простий приклад для початку? Завітайте на [ethereum.org/learn](/learn/) або [ethereum.org/developers.](/developers/) + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Робота з клієнтами Ethereum {#working-with-ethereum-clients} + +Дізнайтеся, як використовувати [Web3J](https://github.com/web3j/web3j) та Hyperledger Besu, два провідні Java-клієнти Ethereum + +- [Підключення до клієнта Ethereum за допомогою Java, Eclipse і Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [Керування обліковим записом Ethereum за допомогою Java і Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [Створення Java-обгортки з вашого смарт-контракту](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [Взаємодія зі смарт-контрактом Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [Прослуховування подій смарт-контрактів Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [Використання Besu (Pantheon), Java-клієнта Ethereum, з Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Запуск вузла Hyperledger Besu (Pantheon) в інтеграційних тестах Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Шпаргалка з Web3j](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) + +Дізнайтеся, як використовувати [ethers-kt](https://github.com/Kr1ptal/ethers-kt), асинхронну, високопродуктивну бібліотеку Kotlin для взаємодії з блокчейнами на основі EVM. Призначено для платформ JVM та Android. + +- [Переказ токенів ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [Обмін на UniswapV2 з прослуховуванням подій](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +- [Трекер балансу ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) + +## Статті для середнього рівня {#intermediate-articles} + +- [Керування сховищем у Java-додатку за допомогою IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [Керування токенами ERC20 в Java за допомогою Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Менеджери транзакцій Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Використання Eventeum для створення кешу даних смарт-контракту Java](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) + +## Проєкти та інструменти Java {#java-projects-and-tools} + +- [Web3J (бібліотека для взаємодії з клієнтами Ethereum)](https://github.com/web3j/web3j) +- [ethers-kt (асинхронна, високопродуктивна бібліотека для Kotlin/Java/Android для блокчейнів на основі EVM.)](https://github.com/Kr1ptal/ethers-kt) +- [Eventeum (прослуховувач подій)](https://github.com/ConsenSys/eventeum) +- [Mahuta (інструменти розробника для IPFS)](https://github.com/ConsenSys/mahuta) + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers.](/developers/) + +## Учасники спільноти Java {#java-community-contributors} + +- [IO Builders](https://io.builders) +- [Kauri](https://kauri.io) diff --git a/public/content/translations/uk/developers/docs/programming-languages/javascript/index.md b/public/content/translations/uk/developers/docs/programming-languages/javascript/index.md new file mode 100644 index 00000000000..5d1a29f13e6 --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/javascript/index.md @@ -0,0 +1,72 @@ +--- +title: "Ethereum для розробників JavaScript" +description: "Дізнайтесь, як покращувати Ethereum за допомогою проектів та інструментів на основі JavaScript." +lang: uk +--- + +JavaScript – найпопулярніша мова в екосистемі Ethereum. Фактично, існує [команда](https://github.com/ethereumjs), яка займається перенесенням якомога більшої частини Ethereum на JavaScript. + +Є можливість писати на JavaScript (або чомусь схожому) на [всіх рівнях стека](/developers/docs/ethereum-stack/). + +## Взаємодія з Ethereum {#interact-with-ethereum} + +### Бібліотеки JavaScript API {#javascript-api-libraries} + +Якщо ви хочете писати на JavaScript для надсилання запитів до блокчейну, відправлення транзакцій тощо, найзручніший спосіб зробити це — використовувати [бібліотеку JavaScript API](/developers/docs/apis/javascript/). Ці API дозволяють розробникам легко взаємодіяти з [вузлами в мережі Ethereum](/developers/docs/nodes-and-clients/). + +Оскільки ці бібліотеки можна використовувати для взаємодії з розумними контрактами на Ethereum, ви можете створити децентралізовану програму всього лише за допомогою мови JavaScript. Так ви зможете працювати зі створеними раніше контрактами. + +**Перегляньте** + +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) – _містить реалізацію гаманця Ethereum та утиліти на JavaScript і TypeScript._ +- [viem](https://viem.sh) – _інтерфейс TypeScript для Ethereum, що надає низькорівневі примітиви без збереження стану для взаємодії з Ethereum._ +- [Drift](https://ryangoree.github.io/drift/) – _метабібліотека TypeScript із вбудованим кешуванням, хуками та тестовими моками для легкої розробки Ethereum у різних бібліотеках web3._ + +### Смарт-контракти {#smart-contracts} + +Якщо ви розробник JavaScript і хочете написати власний смарт-контракт, вам варто ознайомитися з [Solidity](https://solidity.readthedocs.io). Це найпопулярніша мова смарт-контрактів, синтаксично схожа на JavaScript, що може полегшити її вивчення. + +Докладніше про [смарт-контракти](/developers/docs/smart-contracts/). + +## Розуміння протоколу {#understand-the-protocol} + +### Віртуальна машина Ethereum {#the-ethereum-virtual-machine} + +Існує реалізація [віртуальної машини Ethereum](/developers/docs/evm/) на JavaScript. Підтримує правила останнього оновлення. Правила оновлення – це зміни, внесені в налаштування Віртуальної машини Ethereum у результаті запланованих оновлень. + +Їх розділено на різні пакети JavaScript, які ви можете перевірити, щоб ефективніше обробляти наведені нижче елементи: + +- Акаунти +- Блоки +- Алгоритми блокчейну +- Транзакції +- Та багато іншого… + +Це допоможе вам зрозуміти структуру даних облікового запису. + +Якщо ви хочете прочитати код, але не хочете переглядати наші документи, цей код JavaScript може стати чудовою альтернативою. + +**Ознайомтеся з EVM** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) + +### Вузли та клієнти {#nodes-and-clients} + +Клієнт Ethereumjs знаходиться в активній розробці, що дозволяє вам досліджувати, як клієнти Ethereum працюють мовою, яку ви розумієте; JavaScript! + +**Ознайомтеся з клієнтом** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) + +## Інші проєкти {#other-projects} + +Ethereum JavaScript також містить багато інших цікавих речей, зокрема: + +- бібліотеки й утиліти гаманця; +- інструменти для створення, імпортування й експортування ключів Ethereum; +- реалізація `merkle-patricia-tree` – структура даних, описана в Жовтій книзі Ethereum. + +Дізнайтеся більше про те, що вас найбільше цікавить, у [репозиторії EthereumJS](https://github.com/ethereumjs) + +## Для подальшого читання {#further-reading} + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ diff --git a/public/content/translations/uk/developers/docs/programming-languages/python/index.md b/public/content/translations/uk/developers/docs/programming-languages/python/index.md new file mode 100644 index 00000000000..400fcc6653c --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/python/index.md @@ -0,0 +1,99 @@ +--- +title: "Ethereum для розробників на Python" +description: "Дізнайтеся, як розробляти для Ethereum за допомогою проектів та інструментів на основі Python" +lang: uk +incomplete: true +--- + +Дізнайтеся, як розробляти для Ethereum за допомогою проєктів та інструментів на основі Python + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Вони можуть контролювати цифрові активи, щоб створювати нові види фінансових програм. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть свої перші кроки до інтеграції Python із Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Звіт про стан Python у блокчейні за 2023 рік](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) + +## Статті для початківців {#beginner-articles} + +- [Огляд web3.py](https://web3py.readthedocs.io/en/latest/overview.html) +- [Огляд екосистеми Python для Ethereum](https://snakecharmers.ethereum.org/python-ecosystem/) +- [Посібник для розробників Ethereum (на Python)](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [Вартий нагороди: посібник з хакатону Ethereum Python](https://snakecharmers.ethereum.org/prize-worthy/) +- [Вступ до смарт-контрактів з Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Як розробити контракт Ethereum за допомогою Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Вступ до Web3.py · Ethereum для розробників на Python](https://www.dappuniversity.com/articles/web3-py-intro) +- [Як викликати функцію смарт-контракту за допомогою Python та web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) + +## Статті для середнього рівня {#intermediate-articles} + +- [Друзі web3.py: Вступ до Ape](https://snakecharmers.ethereum.org/intro-to-ape/) +- [Розробка Dapp для програмістів на Python](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [Створення інтерфейсу Python для Ethereum: частина 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Смарт-контракти Ethereum на Python: вичерпний(ish) посібник](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Шаблони web3.py: підписки на події в реальному часі](https://snakecharmers.ethereum.org/subscriptions/) +- [Шаблони web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Компіляція, розгортання та виклик смарт-контракту Ethereum за допомогою Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Аналіз смарт-контрактів Solidity за допомогою Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [Посібник з блокчейн-фінтеху: кредитування та запозичення за допомогою Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## Архівовано статті + +- [Розгорніть власний токен ERC20 за допомогою Python та Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [Використання Brownie та Python для розгортання смарт-контрактів](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Створення NFT на OpenSea за допомогою Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## Проєкти та інструменти Python {#python-projects-and-tools} + +### Активні: {#active} + +- [Web3.py](https://github.com/ethereum/web3.py) — _бібліотека Python для взаємодії з Ethereum_ +- [Vyper](https://github.com/ethereum/vyper/) — _Python-подібна мова смарт-контрактів для EVM_ +- [Ape](https://github.com/ApeWorX/ape) — _інструмент розробки смарт-контрактів для пітоністів, фахівців з обробки даних і фахівців з безпеки_ +- [py-evm](https://github.com/ethereum/py-evm) — _реалізація віртуальної машини Ethereum_ +- [eth-tester](https://github.com/ethereum/eth-tester) — _інструменти для тестування застосунків на базі Ethereum_ +- [eth-utils](https://github.com/ethereum/eth-utils/) — _службові функції для роботи з кодовими базами, пов'язаними з Ethereum_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) — _обгортка Python для компілятора solc Solidity з підтримкою версії 0.5.x_ +- [pymaker](https://github.com/makerdao/pymaker) — _Python API для контрактів Maker_ +- [siwe](https://github.com/signinwithethereum/siwe-py) — _вхід за допомогою Ethereum (siwe) для Python_ +- [Web3 DeFi для інтеграцій Ethereum](https://github.com/tradingstrategy-ai/web3-ethereum-defi) — _пакет Python з готовими інтеграціями для ERC-20, Uniswap та інших популярних проєктів_ +- [Wake](https://getwake.io) — _універсальний фреймворк Python для тестування контрактів, фазингу, розгортання, сканування вразливостей і навігації по коду (мовний сервер — [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### Архівовані / Більше не підтримуються: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) — _клієнт Ethereum на Python_ +- [Mamba](https://github.com/arjunaskykok/mamba) — _фреймворк для написання, компіляції та розгортання смарт-контрактів, написаних мовою Vyper_ +- [Brownie](https://github.com/eth-brownie/brownie) — _фреймворк Python для розгортання, тестування та взаємодії зі смарт-контрактами Ethereum_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) — _реалізація стеку Ethereum P2P_ +- [py-wasm](https://github.com/ethereum/py-wasm) — _реалізація на Python інтерпретатора веб-асемблера_ + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers](/developers/). + +## Проєкти, що використовують інструментарій Python {#projects-using-python-tooling} + +Наступні проєкти, засновані на Ethereum, використовують інструменти, згадані на цій сторінці. Відповідні репозиторії з відкритим кодом слугують хорошим посібником для прикладу коду та найкращих практик. + +- [Yearn Finance](https://yearn.finance/) та [репозиторій контрактів Yearn Vault](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/) та [репозиторій смарт-контрактів Curve](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) та [смарт-контракти, що використовують набір інструментів Brownie](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/) використовує [Python для управління та розгортання своїх контрактів вестингу](https://github.com/sushiswap/sushi-vesting-protocols) +- [Alpha Finance](https://alphafinance.io/), відомий своїм проєктом Alpha Homora, використовує [Brownie для тестування та розгортання смарт-контрактів](https://github.com/AlphaFinanceLab/alpha-staking-contract) + +## Обговорення спільноти Python {#python-community-contributors} + +- [Discord спільноти Ethereum Python](https://discord.gg/9zk7snTfWe) для обговорення Web3.py та інших фреймворків Python +- [Discord спільноти Vyper](https://discord.gg/SdvKC79cJk) для обговорення програмування смарт-контрактів на Vyper + +## Інші зведені списки {#other-aggregated-lists} + +Вікі Vyper містить [неймовірний список ресурсів для Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) \ No newline at end of file diff --git a/public/content/translations/uk/developers/docs/programming-languages/ruby/index.md b/public/content/translations/uk/developers/docs/programming-languages/ruby/index.md new file mode 100644 index 00000000000..6144040242f --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/ruby/index.md @@ -0,0 +1,60 @@ +--- +title: "Ethereum для Ruby-розробників" +description: "Дізнайтеся, як розробляти для Ethereum, використовуючи проєкти та інструменти на основі Ruby." +lang: uk +incomplete: false +--- + +Дізнайтеся, як розробляти для Ethereum, використовуючи проєкти та інструменти на основі Ruby. + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть не вимагати довіри, а це означає, що після їх розгортання в Ethereum вони завжди працюватимуть так, як запрограмовано. Вони можуть контролювати цифрові активи для створення нових видів фінансових додатків. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть перші кроки до інтеграції Ruby з Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статті для початківців {#beginner-articles} + +- [Нарешті розбираємося з обліковими записами Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Нарешті автентифікація користувачів Rails за допомогою MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [Як підключитися до мережі Ethereum за допомогою Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [Як згенерувати нову адресу Ethereum у Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) + +## Статті для середнього рівня {#intermediate-articles} + +- [Блокчейн-застосунок з Ruby](https://www.nopio.com/blog/blockchain-app-ruby/) +- [Використання Ruby, підключеного до Ethereum, для виконання смарт-контракту](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) + +## Проєкти та інструменти Ruby {#ruby-projects-and-tools} + +### Активні {#active} + +- [eth.rb](https://github.com/q9f/eth.rb) — _бібліотека Ruby та RPC-клієнт для роботи з обліковими записами, повідомленнями та транзакціями Ethereum_ +- [keccak.rb](https://github.com/q9f/keccak.rb) — _хеш Keccak (SHA3), що використовується в Ethereum_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) — _реалізація Sign-In with Ethereum (вхід за допомогою Ethereum) на Ruby_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) — _гем для Rails, який додає локальні маршрути входу SIWE_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) — _приклад SIWE з використанням Ruby on Rails з користувацьким контролером_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) — _стратегія OmniAuth для Sign In With Ethereum (SIWE)_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) — _стратегія OmniAuth для автентифікації за допомогою володіння NFT_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) — _шаблон Ethereum on Rails, що дозволяє підключати MetaMask до Ruby on Rails_ + +### Заархівовано / Більше не підтримується {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) — _виклик методів RPC вузла Ethereum за допомогою Ruby_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) — _бібліотека Ruby для генерування адрес ETH з ієрархічно-детермінованого гаманця відповідно до стандарту BIP32_ +- [etherlite](https://github.com/budacom/etherlite) — _інтеграція Ethereum для Ruby on Rails_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) — _клієнт Ruby для Ethereum, який використовує інтерфейс JSON-RPC для надсилання транзакцій, створення та взаємодії з контрактами, а також корисний інструментарій для роботи з вузлом Ethereum_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) — _реалізує стратегію провайдера Ethereum для OmniAuth_ + +Шукаєте більше ресурсів? Перегляньте нашу [сторінку для розробників](/developers/). + +## Учасники спільноти Ruby {#ruby-community-contributors} + +[Група Ethereum Ruby у Telegram](https://t.me/ruby_eth) — це місце для спільноти, що швидко зростає, і спеціальний ресурс для обговорення будь-якого з вищезгаданих проєктів і пов'язаних з ними тем. diff --git a/public/content/translations/uk/developers/docs/programming-languages/rust/index.md b/public/content/translations/uk/developers/docs/programming-languages/rust/index.md new file mode 100644 index 00000000000..702b2f5be42 --- /dev/null +++ b/public/content/translations/uk/developers/docs/programming-languages/rust/index.md @@ -0,0 +1,65 @@ +--- +title: "Ethereum для розробників мовою Rust" +description: "Дізнайтеся, як розробляти для Ethereum за допомогою проектів та інструментів на основі Rust" +lang: uk +incomplete: true +--- + +Дізнайтеся, як розробляти для Ethereum за допомогою проєктів та інструментів на основі Rust + +Використовуйте Ethereum для створення децентралізованих програм, що користуються перевагами криптовалюти й технології блокчейну. Ці децентралізовані програми можуть бути надійними, а це означає, що як тільки їх буде запущено в Ethereum, вони завжди працюватимуть так, як їх запрограмовано. Вони можуть контролювати цифрові активи, що допомагає створювати нові види фінансових програм. Ці програми децентралізовані, а це означає, що ними не керують організації або фізичні особи. Крім того, їх майже неможливо піддати цензурі. + +## Початок роботи зі смарт-контрактами та мовою Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Зробіть свої перші кроки до інтеграції Rust із Ethereum** + +Потрібен простий приклад для початку? Перегляньте [ethereum.org/learn](/learn/) або [ethereum.org/developers](/developers/). + +- [Пояснення блокчейну](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Розуміння смарт-контрактів](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишіть свій перший смарт-контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Дізнайтеся, як компілювати та розгортати Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статті для початківців {#beginner-articles} + +- [Клієнт Rust для Ethereum](https://openethereum.github.io/) \* **Примітка: OpenEthereum [визнано застарілим](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) і він більше не підтримується.** Користуйтеся ним з обережністю та бажано перейдіть на іншу реалізацію клієнта. +- [Надсилання транзакцій в Ethereum за допомогою Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Покроковий посібник з написання контрактів на Rust Wasm для Kovan](https://github.com/paritytech/pwasm-tutorial) + +## Статті для середнього рівня {#intermediate-articles} + +## Розширені шаблони використання {#advanced-use-patterns} + +- [Бібліотека pwasm_ethereum externs для взаємодії з мережею, подібною до Ethereum](https://github.com/openethereum/pwasm-ethereum) + +- [Створення децентралізованого чату за допомогою JavaScript та Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) + +- [Створення децентралізованого застосунку зі списком справ за допомогою Vue.js & Rust](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Створення блокчейну на Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Проєкти та інструменти на Rust {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Колекція зовнішніх бібліотек для взаємодії з мережею, подібною до Ethereum_ +- [Lighthouse](https://github.com/sigp/lighthouse) - _Швидкий клієнт рівня консенсусу Ethereum_ +- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Запропонована перебудова рівня виконання смарт-контрактів Ethereum з використанням детермінованої підмножини WebAssembly_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Довідник з API OASIS_ +- [Solaris](https://github.com/paritytech/sol-rs) - _Середовище для модульного тестування смарт-контрактів Solidity з використанням нативного EVM-клієнта Parity._ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Реалізація віртуальної машини Ethereum на Rust_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Смарт-контракт Wavelet на Rust_ +- [Foundry](https://github.com/foundry-rs/foundry) - _Набір інструментів для розробки застосунків Ethereum_ +- [Alloy](https://alloy.rs) - _Високопродуктивні, добре протестовані та задокументовані бібліотеки для взаємодії з Ethereum та іншими ланцюжками на основі EVM._ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Бібліотека Ethereum та реалізація гаманця_ +- [SewUp](https://github.com/second-state/SewUp) - _Бібліотека, яка допоможе вам створювати контракти WebAssembly для Ethereum за допомогою Rust, так само як і розробляти звичайний бекенд_ +- [Substreams](https://github.com/streamingfast/substreams) - _Технологія паралельного індексування даних блокчейну_ +- [Reth](https://github.com/paradigmxyz/reth) Reth (скорочено від Rust Ethereum) — це нова реалізація повного вузла Ethereum +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Підібрана колекція проєктів в екосистемі Ethereum, написаних на Rust_ + +Шукаєте більше ресурсів? Перегляньте [ethereum.org/developers.](/developers/) + +## Учасники спільноти Rust {#rust-community-contributors} + +- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) +- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) +- [Parity Gitter](https://gitter.im/paritytech/parity) +- [Enigma](https://discord.gg/SJK32GY) diff --git a/public/content/translations/uk/developers/docs/scaling/index.md b/public/content/translations/uk/developers/docs/scaling/index.md new file mode 100644 index 00000000000..5922244e072 --- /dev/null +++ b/public/content/translations/uk/developers/docs/scaling/index.md @@ -0,0 +1,113 @@ +--- +title: "Масштабування" +description: "Вступ до різних варіантів масштабування, які в даний час розробляються спільнотою Ethereum." +lang: uk +sidebarDepth: 3 +--- + +## Огляд масштабування {#scaling-overview} + +Оскільки кількість людей, які використовують Ethereum, зросла, блокчейн досяг певних обмежень потужності. Це збільшило вартість використання мережі, створюючи потребу у "масштабуванні рішень." Існує багато рішень для дослідження, перевірки та реалізування, які застосовують різні підходи до досягнення подібних цілей. + +Основна мета масштабованості полягає в тому, щоб збільшити швидкість транзакцій (швидша фіналізація) і пропускну здатність транзакцій (більше транзакцій на секунду), не жертвуючи децентралізацією чи безпекою. У блокчейні Ethereum першого рівня високий попит призводить до сповільнення транзакцій і неприйнятних [цін на газ](/developers/docs/gas/). Розширення потужності мережі з точки зору швидкості й пропускної здатності, є фундаментальним для змістовного та масового впровадження Ethereum. + +Хоча швидкість та пропускна здатність є важливими, важливо, щоб масштабні рішення, що роблять ці цілі можливими, залишалися децентралізованими та безпечними. Збереження бар'єру до низького рівня входу для вузлових операторів має вирішальне значення у запобіганні прогресу через централізовану та незахищену обчислювальну силу. + +Концептуально ми спершу класифікуємо масштабування як масштабування в мережі (onchain) або поза мережею (offchain). + +## Передумови {#prerequisites} + +Вам слід добре розуміти всі основні теми. Реалізація масштабних рішень просувається як не дуже випробувана технологія і продовжує досліджуватися і розроблятися. + +## Масштабування в мережі {#onchain-scaling} + +Масштабування в мережі вимагає змін у протоколі Ethereum (перший рівень [Mainnet](/glossary/#mainnet)). Довгий час очікувалося, що сегментування блокчейну масштабуватиме Ethereum. Це мало на увазі поділ блокчейну на окремі частини (шарди), які перевірятимуться підгрупами валідаторів. Однак масштабування за допомогою зведень (rollups) другого рівня стало основною технікою масштабування. Це підкріплюється додаванням нової, дешевшої форми даних, що прикріплюються до блоків Ethereum, яка спеціально розроблена, щоб зробити зведення (rollups) дешевими для користувачів. + +### Шардинг {#sharding} + +Сегментування — це процес поділу бази даних. Підгрупи валідаторів відповідали б за окремі шарди, а не за відстеження всього Ethereum. Сегментування довго було в [плані розвитку](/roadmap/) Ethereum, і колись планувалося, що його запустять перед The Merge для переходу на доказ частки. Однак швидкий розвиток [зведень другого рівня](#layer-2-scaling) та винахід [Danksharding](/roadmap/danksharding) (додавання blob-об'єктів даних зведень до блоків Ethereum, які можуть дуже ефективно перевірятися валідаторами) призвели до того, що спільнота Ethereum віддала перевагу масштабуванню, орієнтованому на зведення, замість масштабування за допомогою сегментування. Це також допоможе зберегти логіку консенсусу Ethereum простішою. + +## Масштабування поза мережею {#offchain-scaling} + +Рішення поза мережею реалізуються окремо від першого рівня Mainnet — вони не вимагають змін до наявного протоколу Ethereum. Деякі рішення, відомі як рішення «другого рівня», отримують свою безпеку безпосередньо від консенсусу Ethereum першого рівня, наприклад [оптимістичні зведення](/developers/docs/scaling/optimistic-rollups/), [зведення з нульовим розголошенням](/developers/docs/scaling/zk-rollups/) або [канали стану](/developers/docs/scaling/state-channels/). Інші рішення передбачають створення нових ланцюгів у різних формах, які отримують свою безпеку окремо від Mainnet, наприклад [сайдчейни](#sidechains), [validiums](#validium) або [плазмові ланцюги](#plasma). Ці рішення взаємодіють з Mainnet, але по-різному забезпечують свою безпеку для досягнення різноманітних цілей. + +### Масштабування другого рівня {#layer-2-scaling} + +Ця категорія рішень поза мережею отримує свою безпеку від Mainnet Ethereum. + +Layer 2 - загальний термін для рішень, розроблених для допомоги в масштабуванні ваших додатків шляхом проведення транзакцій з Ethereum Mainnet (layer 1), користуючись при цьому перевагами надійної децентралізованої моделі безпеки штату Mainnet. Швидкість транзакції зменшується, коли мережа зайнята, що ускладнює користування певними типами додатків. А коли мережа стає більш завантаженою, ціни на газ зростають, тому що транзагційні відправники намагаються обійти один одного. Це може зробити використання Ethereum дуже дорогим. + +Більшість рішень рівня 2 розташовані навколо сервера або кластера серверів, всі з яких можуть називатися вузлом, валідатором, оператором, послідовністю, блоком чи подібним терміном. Залежно від реалізації, ці вузли 2 рівня можуть керуватися окремими особами, підприємствами або організаціями, які їх використовують, або 3-м оператором, або великою групою людей (як Mainnet). Якщо говорити в загальному, транзакції надсилаються до цих вузлів другого рівня замість подачі безпосередньо до 1 рівня (Mainnet). Для деяких рішень екземпляр другого рівня об'єднує їх у групи, перш ніж закріпити на першому рівні, після чого вони захищаються першим рівнем і не можуть бути змінені. Деталі того, як це робиться суттєво відрізняючись від різних технологій та реалізацій рівень 2. + +Конкретний приклад рівня 2 може бути відкритий і поширений багатьма додатками, або його можна розгорнути одним проєктом і бути призначеним для підтримки тільки свого додатка. + +#### Чому оновлення Eth2 потрібні? {#why-is-layer-2-needed} + +- Збільшення кількості транзакцій за секунду значно покращує взаємодію з користувачем і зменшує перевантаження мережі Mainnet Ethereum. +- Транзакції зводяться в єдину транзакцію в Mainnet Ethereum, що зменшує плату за газ для користувачів і робить Ethereum більш інклюзивним та доступним для людей у всьому світі. +- Будь-які оновлення масштабування не повинні відбуватися за рахунок децентралізації або безпеки - рівень 2 будується поверх Ethereum. +- Існують спеціалізовані мережі другого рівня для застосунків, які забезпечують власний набір переваг ефективності під час роботи з активами в великих масштабах. + +[Докладніше про другий рівень](/layer-2/). + +#### Зведення {#rollups} + +Зведення виконують транзакцію поза 1 рівнем і потім дані будуть розміщені у 1 рівні, де досягнуто консенсусу. Оскільки дані про транзакцію включаються в блоки 1 рівня, це дозволяє забезпечити природною безпекою Ethereum. + +Існує два типи накопичень з різними моделями безпеки: + +- **Оптимістичні зведення**: припускають, що транзакції є дійсними за замовчуванням, і виконують обчислення за допомогою [**доказу шахрайства**](/glossary/#fraud-proof) лише в разі оскарження. [Докладніше про оптимістичні зведення](/developers/docs/scaling/optimistic-rollups/). +- **Зведення з нульовим розголошенням**: виконують обчислення поза мережею та надсилають [**доказ дійсності**](/glossary/#validity-proof) до ланцюга. [Докладніше про зведення з нульовим розголошенням](/developers/docs/scaling/zk-rollups/). + +#### Канали стану {#channels} + +Канали стану використовують контракти з мультипідписом (multisig), щоб дозволити учасникам швидко та вільно здійснювати транзакції поза мережею, а потім фіксувати остаточний стан у Mainnet. Це мінімізує мережеві затори, збори та затримки. Два типи каналів - це наразі канали стану та оплати. + +Дізнайтеся більше про [канали стану](/developers/docs/scaling/state-channels/). + +### Сайдчейни {#sidechains} + +Сайдчейн — це незалежний, сумісний з EVM блокчейн, який працює паралельно з Mainnet. Вони сумісні з Ethereum через двосторонні мости та працюють за власними правилами консенсусу та параметрами блоків. + +Дізнайтеся більше про [сайдчейни](/developers/docs/scaling/sidechains/). + +### Plasma {#plasma} + +Плазмовий ланцюг (plasma chain) — це окремий блокчейн, який прив'язаний до основного ланцюга Ethereum і використовує докази шахрайства (як [оптимістичні зведення](/developers/docs/scaling/optimistic-rollups/)) для вирішення спорів. + +Дізнайтеся більше про [Plasma](/developers/docs/scaling/plasma/). + +### Validium {#validium} + +Validium chain використовує підтвердження дійсності, як-от зведення з нульовим знанням, але дані не зберігаються в основному ланцюжку Ethereum рівня 1. Це може призвести до 10 тисяч транзакцій в секунду на Validium chain, а кілька ланцюжків можна запускати паралельно. + +Дізнайтеся більше про [Validium](/developers/docs/scaling/validium/). + +## Чому необхідно так багато варіантів масштабування? {#why-do-we-need-these} + +- Численні рішення можуть допомогти зменшити загальне перевантаження будь-якої частини мережі, а також запобігти єдиним точкам відмови. +- Ціле - більше, ніж сума його складових. Різні рішення можуть співіснувати та гармонійно працювати, забезпечуючи експоненціальний ефект на швидкість майбутніх транзакцій та продуктивність. +- Не всі рішення вимагають безпосередньо використання алгоритму консенсусу Ethereum, і альтернативи можуть мати вигоду, яку важко досягти інакше. + +## Цікавить наочний матеріал? Для тих, хто навчається візуально {#visual-learner} + + + +_Зауважте, що в поясненні у відео використовується термін "другий рівень" для позначення всіх рішень для масштабування поза мережею, тоді як ми розрізняємо "другий рівень" як рішення поза мережею, що отримує свою безпеку через консенсус першого рівня Mainnet._ + + + +## Для подальшого читання {#further-reading} + +- [Дорожня карта Ethereum, орієнтована на зведення](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Віталік Бутерін_ +- [Актуальна аналітика рішень для масштабування другого рівня для Ethereum](https://www.l2beat.com/) +- [Оцінка рішень для масштабування другого рівня Ethereum: система порівняння](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [Неповний посібник зі зведень](https://vitalik.eth.limo/general/2021/01/05/rollup.html) +- [ZK-Rollups на базі Ethereum: світові лідери](https://hackmd.io/@canti/rkUT0BD8K) +- [Optimistic Rollups проти ZK-Rollups](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [Чому зведення та шарди даних є єдиним стійким рішенням для високої масштабованості](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [Які рівні 3 (Layer 3) мають сенс?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [Доступність даних, або Як зведення навчилися не хвилюватися і полюбили Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [Практичний посібник зі зведень Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ diff --git a/public/content/translations/uk/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/uk/developers/docs/scaling/optimistic-rollups/index.md new file mode 100644 index 00000000000..24afe7985e6 --- /dev/null +++ b/public/content/translations/uk/developers/docs/scaling/optimistic-rollups/index.md @@ -0,0 +1,265 @@ +--- +title: "Оптимістичні накопичення" +description: "Вступ до оптимістичних ролапів — рішення для масштабування, що використовується спільнотою Ethereum." +lang: uk +--- + +Оптимістичні ролапи — це протоколи другого рівня (L2), призначені для розширення пропускної здатності базового рівня Ethereum. Вони зменшують обчислення в основному ланцюзі Ethereum шляхом обробки транзакцій поза ланцюгом (offchain), пропонуючи значні покращення швидкості обробки. На відміну від інших рішень для масштабування, таких як [сайдчейни](/developers/docs/scaling/sidechains/), оптимістичні ролапи отримують безпеку від основної мережі (Mainnet), публікуючи результати транзакцій у ланцюзі (onchain), або [плазмові ланцюги](/developers/docs/scaling/plasma/), які також перевіряють транзакції на Ethereum за допомогою доказів шахрайства, але зберігають дані транзакцій в іншому місці. + +Оскільки обчислення є повільною та дорогою частиною використання Ethereum, оптимістичні ролапи можуть запропонувати покращення масштабованості в 10–100 разів. Оптимістичні ролапи також записують транзакції в Ethereum як `calldata` або в [блоби](/roadmap/danksharding/), зменшуючи витрати на газ для користувачів. + +## Передумови {#prerequisites} + +Вам слід було прочитати й зрозуміти наші сторінки про [масштабування Ethereum](/developers/docs/scaling/) та [шар 2](/layer-2/). + +## Що таке оптимістичний ролап? {#what-is-an-optimistic-rollup} + +Оптимістичний ролап — це підхід до масштабування Ethereum, який передбачає перенесення обчислень і зберігання стану поза ланцюг (offchain). Оптимістичні ролапи виконують транзакції поза Ethereum, але публікують дані транзакцій в основній мережі (Mainnet) як `calldata` або в [блобах](/roadmap/danksharding/). + +Оператори оптимістичних ролапів об’єднують кілька транзакцій поза ланцюгом (offchain) у великі пакети перед їх відправленням до Ethereum. Цей підхід дає змогу розподілити фіксовані витрати між кількома транзакціями в кожному пакеті, зменшуючи комісії для кінцевих користувачів. Оптимістичні ролапи також використовують техніки стиснення, щоб зменшити обсяг даних, що публікуються в Ethereum. + +Оптимістичні ролапи вважаються «оптимістичними», оскільки вони припускають, що транзакції поза ланцюгом (offchain) є дійсними, і не публікують докази дійсності для пакетів транзакцій, розміщених у ланцюзі (onchain). Це відрізняє оптимістичні ролапи від [ZK-ролапів](/developers/docs/scaling/zk-rollups), які публікують криптографічні [докази дійсності](/glossary/#validity-proof) для транзакцій поза ланцюгом (offchain). + +Натомість оптимістичні ролапи покладаються на схему доведення шахрайства для виявлення випадків, коли транзакції обчислюються неправильно. Після того, як пакет ролапу надсилається в Ethereum, існує часове вікно (так званий період оскарження), протягом якого будь-хто може оскаржити результати транзакції ролапу, обчисливши [доказ шахрайства](/glossary/#fraud-proof). + +Якщо доказ шахрайства успішний, протокол ролапу повторно виконує транзакцію(ї) і відповідно оновлює стан ролапу. Іншим наслідком успішного доказу шахрайства є те, що секвенсор, відповідальний за включення неправильно виконаної транзакції в блок, отримує штраф. + +Якщо пакет ролапу залишається неоскарженим (тобто всі транзакції виконані правильно) після закінчення періоду оскарження, він вважається дійсним і приймається в Ethereum. Інші можуть продовжувати будувати на непідтвердженому блоці ролапу, але з одним застереженням: результати транзакцій будуть скасовані, якщо вони базуються на неправильно виконаній транзакції, опублікованій раніше. + +## Як оптимістичні ролапи взаємодіють з Ethereum? {#optimistic-rollups-and-Ethereum} + +Оптимістичні ролапи — це [рішення для масштабування поза ланцюгом](/developers/docs/scaling/#offchain-scaling), створені для роботи поверх Ethereum. Кожен оптимістичний ролап керується набором смарт-контрактів, розгорнутих у мережі Ethereum. Оптимістичні ролапи обробляють транзакції поза основним ланцюгом Ethereum, але публікують транзакції поза ланцюгом (пакетами) до контракту ролапу в ланцюзі (onchain). Подібно до блокчейну Ethereum, цей запис транзакцій є незмінним і формує «ланцюг оптимістичного ролапу». + +Архітектура оптимістичного ролапу складається з таких частин: + +**Контракти в ланцюзі (onchain)**: робота оптимістичного ролапу контролюється смарт-контрактами, що працюють на Ethereum. Це включає контракти, які зберігають блоки ролапу, відстежують оновлення стану в ролапі та депозити користувачів. У цьому сенсі Ethereum слугує базовим рівнем або «рівнем 1» для оптимістичних ролапів. + +**Віртуальна машина поза ланцюгом (VM)**: хоча контракти, що керують протоколом оптимістичного ролапу, працюють на Ethereum, протокол ролапу виконує обчислення та зберігання стану на іншій віртуальній машині, окремо від [віртуальної машини Ethereum](/developers/docs/evm/). VM поза ланцюгом (offchain) — це місце, де працюють програми та виконуються зміни стану; вона слугує верхнім рівнем або «рівнем 2» для оптимістичного ролапу. + +Оскільки оптимістичні ролапи призначені для запуску програм, написаних або скомпільованих для EVM, VM поза ланцюгом (offchain) включає багато специфікацій дизайну EVM. Крім того, докази шахрайства, обчислені в ланцюзі (onchain), дозволяють мережі Ethereum забезпечувати дійсність змін стану, обчислених у VM поза ланцюгом (offchain). + +Оптимістичні ролапи описуються як «гібридні рішення для масштабування», оскільки, хоч вони й існують як окремі протоколи, їхні властивості безпеки походять від Ethereum. Крім іншого, Ethereum гарантує правильність обчислень ролапу поза ланцюгом (offchain) та доступність даних, що лежать в основі цих обчислень. Це робить оптимістичні ролапи більш безпечними, ніж суто протоколи масштабування поза ланцюгом (offchain) (наприклад, [сайдчейни](/developers/docs/scaling/sidechains/)), які не покладаються на Ethereum для забезпечення безпеки. + +Оптимістичні ролапи покладаються на основний протокол Ethereum для наступного: + +### Доступність даних {#data-availability} + +Як уже згадувалося, оптимістичні ролапи публікують дані транзакцій в Ethereum як `calldata` або [блоби](/roadmap/danksharding/). Оскільки виконання ланцюга ролапу базується на надісланих транзакціях, будь-хто може використати цю інформацію, закріплену на базовому рівні Ethereum, для виконання стану ролапу та перевірки правильності переходів стану. + +[Доступність даних](/developers/docs/data-availability/) є критично важливою, оскільки без доступу до даних про стан оскаржувачі не можуть створювати докази шахрайства для оскарження недійсних операцій ролапу. Оскільки Ethereum забезпечує доступність даних, ризик того, що оператори ролапів уникнуть відповідальності за зловмисні дії (наприклад, надсилання недійсних блоків), зменшується. + +### Стійкість до цензури {#censorship-resistance} + +Оптимістичні ролапи також покладаються на Ethereum для забезпечення стійкості до цензури. В оптимістичному ролапі централізована сутність (оператор) відповідає за обробку транзакцій і надсилання блоків ролапу до Ethereum. Це має деякі наслідки: + +- Оператори ролапів можуть цензурувати користувачів, повністю переходячи в офлайн або відмовляючись створювати блоки, які містять певні транзакції. + +- Оператори ролапів можуть перешкоджати користувачам виводити кошти, внесені до контракту ролапу, утримуючи дані про стан, необхідні для доказів володіння Меркла. Утримання даних про стан може також приховувати стан ролапу від користувачів і перешкоджати їм взаємодіяти з ролапом. + +Оптимістичні ролапи вирішують цю проблему, змушуючи операторів публікувати дані, пов'язані з оновленнями стану, на Ethereum. Публікація даних ролапу в ланцюзі (onchain) має такі переваги: + +- Якщо оператор оптимістичного ролапу виходить з мережі або припиняє виробництво пакетів транзакцій, інший вузол може використати доступні дані для відтворення останнього стану ролапу та продовження виробництва блоків. + +- Користувачі можуть використовувати дані транзакцій для створення доказів Меркла, що підтверджують право власності на кошти, і виводити свої активи з ролапу. + +- Користувачі також можуть надсилати свої транзакції на L1 замість секвенсора, і в цьому випадку секвенсор має включити транзакцію протягом певного ліміту часу, щоб продовжувати створювати дійсні блоки. + +### Розрахунок {#settlement} + +Ще одна роль, яку Ethereum відіграє в контексті оптимістичних ролапів, — це роль розрахункового рівня. Розрахунковий рівень закріплює всю екосистему блокчейну, встановлює безпеку та забезпечує об'єктивну завершеність, якщо виникає суперечка в іншому ланцюзі (у цьому випадку оптимістичні ролапи), що вимагає арбітражу. + +Основна мережа Ethereum (Mainnet) надає центр для оптимістичних ролапів для перевірки доказів шахрайства та вирішення суперечок. Крім того, транзакції, проведені на ролапі, стають остаточними _лише_ після того, як блок ролапу буде прийнятий на Ethereum. Щойно транзакція ролапу фіксується на базовому рівні Ethereum, її не можна скасувати (за винятком дуже малоймовірного випадку реорганізації ланцюга). + +## Як працюють оптимістичні ролапи? {#how-optimistic-rollups-work} + +### Виконання й агрегація транзакцій {#transaction-execution-and-aggregation} + +Користувачі надсилають транзакції «операторам», які є вузлами, відповідальними за обробку транзакцій на оптимістичному ролапі. Також відомий як «валідатор» або «агрегатор», оператор агрегує транзакції, стискає базові дані та публікує блок на Ethereum. + +Хоча будь-хто може стати валідатором, валідатори оптимістичних ролапів повинні внести заставу перед створенням блоків, подібно до [системи доказу частки володіння](/developers/docs/consensus-mechanisms/pos/). Цю заставу може бути скорочено (slashed), якщо валідатор опублікує недійсний блок або побудує на старому, але недійсному блоці (навіть якщо його блок є дійсним). Таким чином оптимістичні ролапи використовують криптоекономічні стимули для забезпечення чесної поведінки валідаторів. + +Очікується, що інші валідатори в ланцюзі оптимістичного ролапу виконають надіслані транзакції, використовуючи свою копію стану ролапу. Якщо кінцевий стан валідатора відрізняється від запропонованого оператором стану, вони можуть розпочати оскарження та обчислити доказ шахрайства. + +Деякі оптимістичні ролапи можуть відмовитися від системи валідаторів без дозволів і використовувати єдиний «секвенсор» для виконання ланцюга. Подібно до валідатора, секвенсор обробляє транзакції, створює блоки ролапу та надсилає транзакції ролапу до ланцюга L1 (Ethereum). + +Секвенсор відрізняється від звичайного оператора ролапу, оскільки він має більший контроль над порядком транзакцій. Крім того, секвенсор має пріоритетний доступ до ланцюга ролапу і є єдиною сутністю, уповноваженою надсилати транзакції до контракту в ланцюзі (onchain). Транзакції від вузлів, що не є секвенсорами, або звичайних користувачів просто ставляться в чергу в окрему вхідну скриньку, доки секвенсор не включить їх у новий пакет. + +#### Надсилання блоків ролапу до Ethereum {#submitting-blocks-to-ethereum} + +Як уже згадувалося, оператор оптимістичного ролапу об'єднує транзакції поза ланцюгом у пакет і надсилає його до Ethereum для нотаріального засвідчення. Цей процес включає стиснення даних, пов'язаних з транзакціями, і публікацію їх на Ethereum як `calldata` або в блобах. + +`calldata` — це незмінна, неперсистентна область у смарт-контракті, яка здебільшого поводиться як [пам'ять](/developers/docs/smart-contracts/anatomy/#memory). Хоча `calldata` зберігається в ланцюзі (onchain) як частина [журналів історії](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) блокчейну, вона не зберігається як частина стану Ethereum. Оскільки `calldata` не торкається жодної частини стану Ethereum, вона дешевша за стан для зберігання даних у ланцюзі (onchain). + +Ключове слово `calldata` також використовується в Solidity для передачі аргументів у функцію смарт-контракту під час виконання. `calldata` ідентифікує функцію, що викликається під час транзакції, і містить вхідні дані для функції у вигляді довільної послідовності байтів. + +У контексті оптимістичних ролапів `calldata` використовується для надсилання стиснених даних транзакцій до контракту в ланцюзі (onchain). Оператор ролапу додає новий пакет, викликаючи необхідну функцію в контракті ролапу та передаючи стиснені дані як аргументи функції. Використання `calldata` зменшує комісії для користувачів, оскільки більшість витрат, які несуть ролапи, походять від зберігання даних у ланцюзі (onchain). + +Ось [приклад](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) надсилання пакету ролапу, щоб показати, як працює ця концепція. Секвенсор викликав метод `appendSequencerBatch()` і передав стиснені дані транзакції як вхідні дані за допомогою `calldata`. + +Деякі ролапи тепер використовують блоби для публікації пакетів транзакцій в Ethereum. + +Блоби є незмінними та неперсистентними (так само, як `calldata`), але видаляються з історії приблизно через 18 днів. Для отримання додаткової інформації про блоби див. [Danksharding](/roadmap/danksharding). + +### Зобов'язання щодо стану {#state-commitments} + +У будь-який момент часу стан оптимістичного ролапу (облікові записи, баланси, код контракту тощо) організований як [дерево Меркла](/whitepaper/#merkle-trees), що називається «деревом стану». Корінь цього дерева Меркла (корінь стану), який посилається на останній стан ролапу, хешується і зберігається в контракті ролапу. Кожен перехід стану в ланцюзі створює новий стан ролапу, який оператор фіксує, обчислюючи новий корінь стану. + +Оператор зобов'язаний надсилати як старі, так і нові корені стану під час публікації пакетів. Якщо старий корінь стану збігається з наявним коренем стану в контракті в ланцюзі (onchain), останній відкидається і замінюється новим коренем стану. + +Оператор ролапу також зобов'язаний фіксувати корінь Меркла для самого пакету транзакцій. Це дозволяє будь-кому довести включення транзакції до пакету (на L1), пред'явивши [доказ Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). + +Фіксації стану, особливо корені стану, необхідні для доведення правильності змін стану в оптимістичному ролапі. Контракт ролапу приймає нові корені стану від операторів одразу після їх публікації, але може пізніше видалити недійсні корені стану, щоб відновити ролап до його правильного стану. + +### Доведення шахрайства {#fraud-proving} + +Як пояснено, оптимістичні ролапи дозволяють будь-кому публікувати блоки без надання доказів дійсності. Однак, щоб забезпечити безпеку ланцюга, оптимістичні ролапи визначають часове вікно, протягом якого будь-хто може оскаржити перехід стану. Тому блоки ролапу називаються «твердженнями», оскільки будь-хто може оскаржити їхню дійсність. + +Якщо хтось оскаржує твердження, протокол ролапу ініціює обчислення доказу шахрайства. Кожен тип доказу шахрайства є інтерактивним — хтось повинен опублікувати твердження, перш ніж інша особа зможе його оскаржити. Різниця полягає в тому, скільки раундів взаємодії потрібно для обчислення доказу шахрайства. + +Схеми доведення з одним раундом інтерактивності повторюють оскаржені транзакції на L1 для виявлення недійсних тверджень. Протокол ролапу емулює повторне виконання оскарженої транзакції на L1 (Ethereum) за допомогою контракту-верифікатора, при цьому обчислений корінь стану визначає, хто виграє оскарження. Якщо твердження оскаржувача про правильний стан ролапу є вірним, оператор карається скороченням його застави. + +Однак повторне виконання транзакцій на L1 для виявлення шахрайства вимагає публікації фіксацій стану для окремих транзакцій і збільшує обсяг даних, які ролапи повинні публікувати в ланцюзі (onchain). Повторне відтворення транзакцій також спричиняє значні витрати на газ. З цих причин оптимістичні ролапи переходять на багаторандове інтерактивне доведення, яке досягає тієї ж мети (тобто виявлення недійсних операцій ролапу) з більшою ефективністю. + +#### Багаторандове інтерактивне доведення {#multi-round-interactive-proving} + +Багаторандове інтерактивне доведення включає протокол взаємодії між тим, хто стверджує, і тим, хто оскаржує, під наглядом контракту-верифікатора L1, який в кінцевому підсумку визначає сторону, що бреше. Після того, як вузол L2 оскаржує твердження, той, хто стверджує, повинен розділити оскаржене твердження на дві рівні половини. Кожне окреме твердження в цьому випадку міститиме стільки ж кроків обчислень, скільки й інше. + +Тоді оскаржувач обере, яке твердження він хоче оскаржити. Процес поділу (так званий «протокол бісекції») триває доти, доки обидві сторони не сперечатимуться щодо твердження про _один_ крок виконання. На цьому етапі контракт L1 вирішить суперечку, оцінивши інструкцію (та її результат), щоб виявити шахрайську сторону. + +Той, хто стверджує, зобов'язаний надати «однокроковий доказ», що підтверджує дійсність оскарженого однокрокового обчислення. Якщо той, хто стверджує, не надає однокроковий доказ, або верифікатор L1 визнає доказ недійсним, він програє оскарження. + +Деякі примітки щодо цього типу доказу шахрайства: + +1. Багаторандове інтерактивне доведення шахрайства вважається ефективним, оскільки воно мінімізує роботу, яку ланцюг L1 повинен виконати в арбітражі суперечок. Замість повторного відтворення всієї транзакції, ланцюгу L1 потрібно лише повторно виконати один крок у виконанні ролапу. + +2. Протоколи бісекції зменшують кількість даних, що публікуються в ланцюзі (onchain) (немає необхідності публікувати фіксації стану для кожної транзакції). Крім того, транзакції оптимістичних ролапів не обмежені лімітом газу Ethereum. Навпаки, оптимістичні ролапи, що повторно виконують транзакції, повинні переконатися, що транзакція L2 має нижчий ліміт газу, щоб емулювати її виконання в рамках однієї транзакції Ethereum. + +3. Частина застави зловмисного стверджувача присуджується оскаржувачу, а інша частина спалюється. Спалювання запобігає змові між валідаторами; якщо два валідатори вступають у змову для ініціювання фіктивних оскаржень, вони все одно втратять значну частину всієї ставки. + +4. Багаторандове інтерактивне доведення вимагає, щоб обидві сторони (стверджувач і оскаржувач) робили ходи протягом зазначеного часового вікна. Нездатність діяти до закінчення терміну призводить до того, що сторона, яка не виконала зобов'язання, програє оскарження. + +#### Чому докази шахрайства важливі для оптимістичних ролапів {#fraud-proof-benefits} + +Докази шахрайства важливі, оскільки вони сприяють _бездовірній завершеності_ в оптимістичних ролапах. Бездовірна завершеність — це якість оптимістичних ролапів, яка гарантує, що транзакція — за умови, що вона дійсна — врешті-решт буде підтверджена. + +Зловмисні вузли можуть намагатися затримати підтвердження дійсного блоку ролапу, розпочинаючи хибні оскарження. Однак докази шахрайства врешті-решт доведуть дійсність блоку ролапу і призведуть до його підтвердження. + +Це також пов'язано з іншою властивістю безпеки оптимістичних ролапів: дійсність ланцюга залежить від існування _одного_ чесного вузла. Чесний вузол може правильно просувати ланцюг, або публікуючи дійсні твердження, або оскаржуючи недійсні твердження. У будь-якому випадку, зловмисні вузли, які вступають у суперечки з чесним вузлом, втратять свої ставки під час процесу доведення шахрайства. + +### Сумісність L1/L2 {#l1-l2-interoperability} + +Оптимістичні ролапи розроблені для взаємодії з основною мережею Ethereum і дозволяють користувачам передавати повідомлення та довільні дані між L1 і L2. Вони також сумісні з EVM, тому ви можете переносити наявні [dApps](/developers/docs/dapps/) на оптимістичні ролапи або створювати нові dApps за допомогою інструментів розробки Ethereum. + +#### 1. Переміщення активів {#asset-movement} + +##### Вхід до ролапу + +Щоб використовувати оптимістичний ролап, користувачі вносять ETH, токени ERC-20 та інші прийняті активи в [мостовий](/developers/docs/bridges/) контракт ролапу на L1. Мостовий контракт передасть транзакцію на L2, де еквівалентна кількість активів буде випущена і відправлена на обрану користувачем адресу на оптимістичному ролапі. + +Транзакції, що генеруються користувачами (наприклад, депозит L1 > L2), зазвичай ставляться в чергу, доки секвенсор не надішле їх повторно до контракту ролапу. Однак, щоб зберегти стійкість до цензури, оптимістичні ролапи дозволяють користувачам надсилати транзакцію безпосередньо до контракту ролапу в ланцюзі (onchain), якщо вона була затримана довше максимально дозволеного часу. + +Деякі оптимістичні ролапи використовують більш простий підхід для запобігання цензурі користувачів секвенсорами. Тут блок визначається всіма транзакціями, надісланими до контракту L1 з моменту попереднього блоку (наприклад, депозити), на додаток до транзакцій, оброблених у ланцюзі ролапу. Якщо секвенсор ігнорує транзакцію L1, він опублікує (доказово) неправильний корінь стану; отже, секвенсори не можуть затримувати повідомлення, згенеровані користувачами, після їх публікації на L1. + +##### Вихід з ролапу + +Виведення з оптимістичного ролапу до Ethereum є складнішим через схему доведення шахрайства. Якщо користувач ініціює транзакцію L2 > L1 для виведення коштів, заблокованих на L1, він повинен зачекати, доки закінчиться період оскарження, що триває приблизно сім днів. Проте, сам процес виведення є досить простим. + +Після ініціювання запиту на виведення на ролапі L2 транзакція включається в наступний пакет, а активи користувача на ролапі спалюються. Щойно пакет буде опубліковано на Ethereum, користувач може обчислити доказ Меркла, що підтверджує включення його транзакції виходу до блоку. Потім залишається лише зачекати протягом періоду затримки, щоб завершити транзакцію на L1 і вивести кошти до основної мережі (Mainnet). + +Щоб уникнути очікування тижня перед виведенням коштів до Ethereum, користувачі оптимістичних ролапів можуть скористатися послугами **постачальника ліквідності** (LP). Постачальник ліквідності бере на себе право власності на очікуване виведення L2 і виплачує кошти користувачеві на L1 (в обмін на комісію). + +Постачальники ліквідності можуть перевірити дійсність запиту користувача на виведення (виконавши ланцюг самостійно) перед тим, як випустити кошти. Таким чином вони мають гарантії, що транзакція врешті-решт буде підтверджена (тобто бездовірна завершеність). + +#### 2. Сумісність з EVM {#evm-compatibility} + +Для розробників перевагою оптимістичних ролапів є їхня сумісність — або, ще краще, еквівалентність — з [віртуальною машиною Ethereum (EVM)](/developers/docs/evm/). EVM-сумісні ролапи відповідають специфікаціям [жовтої книги Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) і підтримують EVM на рівні байткоду. + +EVM-сумісність в оптимістичних ролапах має такі переваги: + +i. Розробники можуть переносити наявні смарт-контракти на Ethereum до ланцюгів оптимістичних ролапів без необхідності значно змінювати кодові бази. Це може заощадити час команд розробників під час розгортання смарт-контрактів Ethereum на L2. + +ii. Розробники та проєктні команди, що використовують оптимістичні ролапи, можуть скористатися інфраструктурою Ethereum. Це включає мови програмування, бібліотеки коду, інструменти тестування, клієнтське програмне забезпечення, інфраструктуру розгортання тощо. + +Використання наявних інструментів є важливим, оскільки ці інструменти були ретельно перевірені, налагоджені та вдосконалені протягом багатьох років. Це також усуває необхідність для розробників Ethereum вивчати, як створювати з абсолютно новим стеком розробки. + +#### 3. Міжланцюгові виклики контрактів {#cross-chain-contract-calls} + +Користувачі (зовнішні облікові записи) взаємодіють з контрактами L2, надсилаючи транзакцію до контракту ролапу або доручаючи це секвенсору чи валідатору. Оптимістичні ролапи також дозволяють контрактним обліковим записам на Ethereum взаємодіяти з контрактами L2 за допомогою мостових контрактів для передачі повідомлень і даних між L1 і L2. Це означає, що ви можете запрограмувати контракт L1 на основній мережі Ethereum для виклику функцій, що належать контрактам на оптимістичному ролапі L2. + +Міжланцюгові виклики контрактів відбуваються асинхронно — тобто виклик спочатку ініціюється, а потім виконується пізніше. Це відрізняється від викликів між двома контрактами на Ethereum, де виклик дає результати негайно. + +Прикладом міжланцюгового виклику контракту є депозит токенів, описаний раніше. Контракт на L1 блокує токени користувача та надсилає повідомлення парному контракту на L2 для випуску еквівалентної кількості токенів на ролапі. + +Оскільки міжланцюгові виклики повідомлень призводять до виконання контракту, відправник зазвичай зобов'язаний покрити [витрати на газ](/developers/docs/gas/) для обчислень. Бажано встановити високий ліміт газу, щоб запобігти збою транзакції в цільовому ланцюзі. Сценарій мостування токенів є хорошим прикладом; якщо сторона транзакції L1 (депозит токенів) працює, але сторона L2 (випуск нових токенів) зазнає невдачі через низький газ, депозит стає незворотнім. + +Нарешті, слід зазначити, що виклики повідомлень L2 > L1 між контрактами повинні враховувати затримки (виклики L1 > L2 зазвичай виконуються через кілька хвилин). Це пов'язано з тим, що повідомлення, надіслані до основної мережі (Mainnet) з оптимістичного ролапу, не можуть бути виконані до закінчення вікна оскарження. + +## Як працюють комісії в оптимістичних ролапах? {#how-do-optimistic-rollup-fees-work} + +Оптимістичні ролапи використовують схему комісій за газ, подібно до Ethereum, щоб визначити, скільки користувачі платять за транзакцію. Комісії, що стягуються в оптимістичних ролапах, залежать від таких компонентів: + +1. **Запис стану**: оптимістичні ролапи публікують дані транзакцій і заголовки блоків (що складаються з хеша заголовка попереднього блоку, кореня стану, кореня пакета) в Ethereum як `blob`, або «великий бінарний об'єкт». [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) запровадив економічно вигідне рішення для включення даних у ланцюг (onchain). `blob` — це нове поле транзакції, яке дозволяє ролапам публікувати стиснені дані про перехід стану до L1 Ethereum. На відміну від `calldata`, яка залишається в ланцюзі (onchain) назавжди, блоби є короткоживучими і можуть бути видалені з клієнтів після [4096 епох](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (приблизно 18 днів). Використовуючи блоби для публікації пакетів стиснених транзакцій, оптимістичні ролапи можуть значно зменшити вартість запису транзакцій до L1. + +2. **Використаний газ для блобів**: транзакції, що переносять блоби, використовують динамічний механізм комісій, схожий на той, що був запроваджений [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Комісія за газ для транзакцій типу 3 враховує базову комісію для блобів, яка визначається мережею на основі попиту на простір блобів та використання простору блобів транзакцією, що надсилається. + +3. **Комісії оператора L2**: це сума, що виплачується вузлам ролапу як компенсація за обчислювальні витрати, понесені під час обробки транзакцій, подібно до комісій за газ на Ethereum. Вузли ролапу стягують нижчі комісії за транзакції, оскільки L2 мають вищу пропускну здатність і не стикаються з перевантаженнями мережі, які змушують валідаторів на Ethereum пріоритезувати транзакції з вищими комісіями. + +Оптимістичні ролапи застосовують кілька механізмів для зменшення комісій для користувачів, включаючи пакетування транзакцій та стиснення `calldata` для зменшення витрат на публікацію даних. Ви можете перевірити [трекер комісій L2](https://l2fees.info/), щоб у реальному часі побачити, скільки коштує використання оптимістичних ролапів на базі Ethereum. + +## Як оптимістичні ролапи масштабують Ethereum? {#scaling-ethereum-with-optimistic-rollups} + +Як пояснено, оптимістичні ролапи публікують стиснені дані транзакцій на Ethereum для гарантування доступності даних. Можливість стискати дані, що публікуються в ланцюзі (onchain), є ключовою для масштабування пропускної здатності на Ethereum за допомогою оптимістичних ролапів. + +Основний ланцюг Ethereum встановлює обмеження на кількість даних, які можуть містити блоки, виражені в одиницях газу ([середній розмір блоку](/developers/docs/blocks/#block-size) становить 15 мільйонів газу). Хоча це обмежує кількість газу, яку може використовувати кожна транзакція, це також означає, що ми можемо збільшити кількість оброблених транзакцій за блок, зменшивши дані, пов'язані з транзакціями, що безпосередньо покращує масштабованість. + +Оптимістичні ролапи використовують кілька технік для досягнення стиснення даних транзакцій і підвищення показників TPS. Наприклад, ця [стаття](https://vitalik.eth.limo/general/2021/01/05/rollup.html) порівнює дані, які генерує базова транзакція користувача (надсилання ефіру) в основній мережі (Mainnet), з тим, скільки даних генерує та ж транзакція на ролапі: + +| Параметр | Ethereum (L1) | Ролап (L2) | +| ---------- | ---------------------------------------------------- | ------------------------------------ | +| Nonce | ~3 | 0 | +| Ціна газу | ~8 | 0-0.5 | +| Gas | 3 | 0-0.5 | +| Кому | 21 | 4 | +| Значення | 9 | ~3 | +| Signature | ~68 (2 + 33 + 33) | ~0.5 | +| Від | 0 (відновлено з підпису) | 4 | +| **Усього** | **~112 байт** | **~12 байт** | + +Виконання деяких приблизних розрахунків на основі цих цифр може допомогти показати покращення масштабованості, які надає оптимістичний ролап: + +1. Цільовий розмір кожного блоку — 15 мільйонів газу, а вартість перевірки одного байта даних — 16 газу. Поділивши середній розмір блоку на 16 газу (15 000 000 / 16), отримаємо, що середній блок може вмістити **937 500 байтів даних**. +2. Якщо базова транзакція ролапу використовує 12 байт, то середній блок Ethereum може обробити **78 125 транзакцій ролапу** (937 500 / 12) або **39 пакетів ролапу** (якщо кожен пакет містить в середньому 2 000 транзакцій). +3. Якщо новий блок створюється на Ethereum кожні 15 секунд, то швидкість обробки ролапу становитиме приблизно **5 208 транзакцій на секунду**. Це розраховується шляхом ділення кількості базових транзакцій ролапу, які може вмістити блок Ethereum (**78 125**), на середній час блокування (**15 секунд**). + +Це досить оптимістична оцінка, враховуючи, що транзакції оптимістичних ролапів не можуть повністю заповнити блок на Ethereum. Однак, це може дати приблизне уявлення про те, наскільки великий приріст масштабованості можуть забезпечити оптимістичні ролапи для користувачів Ethereum (поточні реалізації пропонують до 2000 TPS). + +Очікується, що впровадження [шардингу даних](/roadmap/danksharding/) на Ethereum покращить масштабованість оптимістичних ролапів. Оскільки транзакції ролапів повинні ділити простір блоку з іншими транзакціями, що не є ролапами, їхня пропускна здатність обмежена пропускною здатністю даних на основному ланцюзі Ethereum. Danksharding збільшить простір, доступний для ланцюгів L2 для публікації даних у блоці, використовуючи дешевше, неперманентне сховище «блобів» замість дорогого, перманентного `CALLDATA`. + +### Плюси та мінуси оптимістичних ролапів {#optimistic-rollups-pros-and-cons} + +| Переваги | Недоліки | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Пропонує значне покращення масштабованості без шкоди для безпеки чи бездовірності. | Затримки у фіналізації транзакцій через потенційні оскарження шахрайства. | +| Дані транзакцій зберігаються на ланцюзі першого рівня, що покращує прозорість, безпеку, стійкість до цензури та децентралізацію. | Централізовані оператори ролапів (секвенсори) можуть впливати на порядок транзакцій. | +| Доведення шахрайства гарантує бездовірну завершеність і дозволяє чесним меншинам захищати ланцюг. | Якщо немає чесних вузлів, зловмисний оператор може вкрасти кошти, публікуючи недійсні блоки та фіксації стану. | +| Обчислення доказів шахрайства є відкритим для звичайних вузлів L2, на відміну від доказів дійсності (що використовуються в ZK-ролапах), які вимагають спеціального обладнання. | Модель безпеки покладається на те, що принаймні один чесний вузол виконує транзакції ролапу та подає докази шахрайства для оскарження недійсних переходів стану. | +| Ролапи отримують перевагу від «бездовірної живучості» (будь-хто може змусити ланцюг просуватися, виконуючи транзакції та публікуючи твердження). | Користувачі повинні чекати, поки закінчиться тижневий період оскарження, перш ніж виводити кошти назад до Ethereum. | +| Оптимістичні ролапи покладаються на добре продумані криптоекономічні стимули для підвищення безпеки ланцюга. | Ролапи повинні публікувати всі дані транзакцій у ланцюзі (onchain), що може збільшити витрати. | +| Сумісність з EVM та Solidity дозволяє розробникам переносити нативні смарт-контракти Ethereum на ролапи або використовувати наявні інструменти для створення нових dApps. | | + +### Наочне пояснення оптимістичних ролапів {#optimistic-video} + +Цікавить наочний матеріал? Подивіться як Finematics пояснює оптимістичні підсумки: + + + +## Додаткова література про оптимістичні ролапи + +- [Як працюють оптимістичні ролапи (повний посібник)](https://www.alchemy.com/overviews/optimistic-rollups) +- [Що таке блокчейн-ролап? Технічний вступ](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) +- [Основний посібник з Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [Практичний посібник з ролапів Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [Стан доказів шахрайства в L2-рішеннях Ethereum](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [Як насправді працює ролап Optimism?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [Глибоке занурення в OVM](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [Що таке оптимістична віртуальна машина?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/uk/developers/docs/scaling/plasma/index.md b/public/content/translations/uk/developers/docs/scaling/plasma/index.md new file mode 100644 index 00000000000..f157b19e1b6 --- /dev/null +++ b/public/content/translations/uk/developers/docs/scaling/plasma/index.md @@ -0,0 +1,176 @@ +--- +title: "Плазмові ланцюги" +description: "Введення плазмових ланцюгів як рішення для масштабування, яке зараз використовується спільнотою Ethereum." +lang: uk +incomplete: true +sidebarDepth: 3 +--- + +Ланцюжок Plasma — це окремий блокчейн, прив'язаний до основної мережі Ethereum, але він виконує транзакції поза ланцюгом за допомогою власного механізму перевірки блоків. Ланцюжки Plasma іноді називають «дочірніми» ланцюжками, по суті, меншими копіями основної мережі Ethereum. Ланцюжки Plasma використовують [докази шахрайства](/glossary/#fraud-proof) (подібно до [оптимістичних зведень](/developers/docs/scaling/optimistic-rollups/)) для вирішення суперечок. + +Дерева Меркла дають змогу створювати нескінченний стек цих ланцюжків, які можуть працювати для розвантаження пропускної здатності від батьківських ланцюжків (включно з основною мережею Ethereum). Однак, хоча ці ланцюжки й отримують певну безпеку від Ethereum (за допомогою доказів шахрайства), на їхню безпеку та ефективність впливають кілька обмежень конструкції. + +## Передумови {#prerequisites} + +Ви повинні добре розуміти всі основні теми та мати загальне уявлення про [масштабування Ethereum](/developers/docs/scaling/). + +## Що таке Plasma? + +Plasma — це фреймворк для покращення масштабованості в загальнодоступних блокчейнах, як-от Ethereum. Як описано в оригінальному [документі Plasma](http://plasma.io/plasma.pdf), ланцюжки Plasma будуються поверх іншого блокчейну (так званого «кореневого ланцюжка»). Кожен «дочірній ланцюжок» розширюється від кореневого ланцюжка та зазвичай керується смарт-контрактом, розгорнутим у батьківському ланцюжку. + +Контракт Plasma, серед іншого, функціонує як [міст](/developers/docs/bridges/), що дозволяє користувачам переміщувати активи між основною мережею Ethereum і ланцюжком Plasma. Хоча це робить їх схожими на [сайдчейни](/developers/docs/scaling/sidechains/), ланцюжки Plasma певною мірою отримують переваги від безпеки основної мережі Ethereum. Це не схоже на сайдчейни, які несуть повну відповідальність за свою безпеку. + +## Як працює Plasma? + +Основними компонентами фреймворку Plasma є: + +### Позаланцюгові обчислення {#offchain-computation} + +Поточна швидкість обробки Ethereum обмежена ~ 15-20 транзакціями на секунду, що зменшує короткострокову можливість масштабування для обробки більшої кількості користувачів. Ця проблема існує головним чином тому, що [механізм консенсусу](/developers/docs/consensus-mechanisms/) Ethereum вимагає, щоб багато вузлів P2P перевіряли кожне оновлення стану блокчейну. + +Хоча механізм консенсусу Ethereum необхідний для безпеки, він може застосовуватися не в кожному випадку використання. Наприклад, Еліс може не потребувати, щоб її щоденні платежі Бобу за чашку кави перевірялися всією мережею Ethereum, оскільки між обома сторонами існує певна довіра. + +Plasma припускає, що основна мережа Ethereum не потребує перевірки всіх транзакцій. Замість цього ми можемо обробляти транзакції поза основною мережею, звільняючи вузли від необхідності перевіряти кожну транзакцію. + +Обчислення поза ланцюжком необхідні, оскільки ланцюжки Plasma можуть оптимізувати швидкість і вартість. Наприклад, ланцюжок Plasma може — і найчастіше так і робить — використовувати єдиного «оператора» для керування впорядкуванням і виконанням транзакцій. Оскільки транзакції перевіряє лише одна сутність, час обробки в ланцюжку Plasma менший, ніж в основній мережі Ethereum. + +### Зобов'язання щодо стану {#state-commitments} + +Хоча Plasma виконує транзакції поза ланцюгом, вони обробляються на основному виконавчому рівні Ethereum — інакше ланцюжки Plasma не можуть скористатися гарантіями безпеки Ethereum. Але завершення транзакцій поза ланцюжком без знання стану ланцюжка Plasma порушило б модель безпеки та дозволило б поширювати недійсні транзакції. Ось чому оператор, сутність, відповідальна за створення блоків у ланцюжку Plasma, зобов’язаний періодично публікувати «зобов’язання щодо стану» в Ethereum. + +[Схема зобов'язань](https://en.wikipedia.org/wiki/Commitment_scheme) — це криптографічний метод зобов'язання щодо значення або твердження без його розкриття іншій стороні. Зобов'язання є «обов'язковими» в тому сенсі, що ви не можете змінити значення або твердження після того, як ви взяли на себе зобов'язання. Зобов’язання щодо стану в Plasma мають форму «коренів Меркла» (похідних від [дерева Меркла](/whitepaper/#merkle-trees)), які оператор з інтервалами надсилає до контракту Plasma в ланцюжку Ethereum. + +Корені Меркла — це криптографічні примітиви, які дозволяють стискати великі обсяги інформації. Корінь Меркла (у цьому випадку також називається «коренем блоку») може представляти всі транзакції в блоці. Корені Меркла також полегшують перевірку того, що невелика частина даних є частиною більшого набору даних. Наприклад, користувач може створити [доказ Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content), щоб довести включення транзакції в певний блок. + +Корені Меркла важливі для надання інформації про стан поза ланцюгом для Ethereum. Ви можете думати про корені Меркла як про «точки збереження»: оператор каже: «Це стан ланцюжка Plasma в момент часу x, а це корінь Меркла як доказ». Оператор зобов'язується щодо _поточного стану_ ланцюжка Plasma з коренем Меркла, тому це називається «зобов'язанням щодо стану». + +### Входи та виходи {#entries-and-exits} + +Щоб користувачі Ethereum могли скористатися перевагами Plasma, потрібен механізм переміщення коштів між основною мережею та ланцюжками Plasma. Однак ми не можемо довільно надсилати етер на адресу в ланцюжку Plasma — ці ланцюжки несумісні, тому транзакція або не вдасться, або призведе до втрати коштів. + +Plasma використовує головний контракт, що працює на Ethereum, для обробки входів і виходів користувачів. Цей головний контракт також відповідає за відстеження зобов’язань щодо стану (пояснено раніше) і покарання за нечесну поведінку за допомогою доказів шахрайства (докладніше про це пізніше). + +#### Вхід до ланцюжка Plasma {#entering-the-plasma-chain} + +Щоб увійти до ланцюжка Plasma, Еліс (користувач) повинна буде внести ETH або будь-який токен ERC-20 у контракт Plasma. Оператор Plasma, який стежить за депозитами за контрактом, відтворює суму, що дорівнює початковому депозиту Еліс, і переказує її на її адресу в ланцюжку Plasma. Еліс зобов’язана підтвердити отримання коштів у дочірньому ланцюжку, а потім може використовувати ці кошти для транзакцій. + +#### Вихід із ланцюжка Plasma {#exiting-the-plasma-chain} + +Вихід із ланцюжка Plasma є складнішим, ніж вхід до нього, з кількох причин. Найбільша з них полягає в тому, що, хоча Ethereum має інформацію про стан ланцюжка Plasma, він не може перевірити, правдива ця інформація чи ні. Зловмисний користувач може зробити невірне твердження («У мене є 1000 ETH») і залишитися безкарним, надавши підроблені докази на підтвердження своєї заяви. + +Щоб запобігти зловмисному виведенню коштів, вводиться «період оскарження». Протягом періоду оскарження (зазвичай тиждень) будь-хто може оскаржити запит на зняття коштів за допомогою доказу шахрайства. Якщо оскарження буде успішним, запит на зняття коштів буде відхилено. + +Однак зазвичай користувачі є чесними та роблять правильні заяви щодо коштів, якими вони володіють. У цьому сценарії Еліс ініціює запит на виведення коштів у кореневому ланцюжку (Ethereum), надіславши транзакцію до контракту Plasma. + +Вона також повинна надати доказ Меркла, який підтверджує, що транзакція зі створення її коштів у ланцюжку Plasma була включена до блоку. Це необхідно для ітерацій Plasma, як-от [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), які використовують модель [невитрачених виходів транзакцій (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). + +Інші, як-от [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), представляють кошти як [невзаємозамінні токени](/developers/docs/standards/tokens/erc-721/) замість UTXO. У цьому випадку виведення коштів вимагає підтвердження права власності на токени в ланцюжку Plasma. Це робиться шляхом надсилання двох останніх транзакцій за участю токена та надання доказу Меркла, що підтверджує включення цих транзакцій до блоку. + +Користувач також повинен додати заставу до запиту на виведення коштів як гарантію чесної поведінки. Якщо претендент доведе, що запит Еліс на виведення коштів є недійсним, її заставу буде скорочено, а частина її дістанеться претенденту як винагорода. + +Якщо період оскарження мине, і ніхто не надасть доказів шахрайства, запит Еліс на виведення коштів вважається дійсним, що дозволяє їй отримати депозити з контракту Plasma на Ethereum. + +### Арбітраж спорів {#dispute-arbitration} + +Як і будь-який блокчейн, ланцюжки Plasma потребують механізму для забезпечення цілісності транзакцій у випадку, якщо учасники діють зловмисно (наприклад, подвійно витрачають кошти). З цією метою ланцюжки Plasma використовують докази шахрайства для вирішення суперечок щодо дійсності переходів стану та покарання за погану поведінку. Докази шахрайства використовуються як механізм, за допомогою якого дочірній ланцюжок Plasma подає скаргу до свого батьківського ланцюжка або до кореневого ланцюжка. + +Доказ шахрайства — це просто твердження про те, що певний перехід стану є недійсним. Прикладом може бути ситуація, коли користувач (Еліс) намагається витратити одні й ті ж кошти двічі. Можливо, вона витратила UTXO в транзакції з Бобом і хоче витратити той самий UTXO (який тепер належить Бобу) в іншій транзакції. + +Щоб запобігти виведенню коштів, Боб створить доказ шахрайства, надавши докази того, що Еліс витратила згаданий UTXO в попередній транзакції, і доказ Меркла про включення транзакції до блоку. Той самий процес працює і в Plasma Cash — Бобу потрібно буде надати докази того, що Еліс раніше переказала токени, які вона намагається вивести. + +Якщо оскарження Боба вдасться, запит Еліс на виведення коштів скасовується. Однак цей підхід покладається на здатність Боба стежити за ланцюжком запитів на виведення коштів. Якщо Боб перебуває в автономному режимі, Еліс може обробити зловмисне виведення коштів після закінчення періоду оскарження. + +## Проблема масового виходу в Plasma {#the-mass-exit-problem-in-plasma} + +Проблема масового виходу виникає, коли велика кількість користувачів намагається одночасно вивести кошти з ланцюжка Plasma. Чому ця проблема існує, пов'язано з однією з найбільших проблем Plasma: **недоступністю даних**. + +Доступність даних — це можливість перевірити, чи інформація для запропонованого блоку дійсно була опублікована в мережі блокчейн. Блок «недоступний», якщо виробник публікує сам блок, але приховує дані, використані для створення блоку. + +Блоки повинні бути доступні, щоб вузли могли завантажувати блок і перевіряти дійсність транзакцій. Блокчейни забезпечують доступність даних, змушуючи виробників блоків розміщувати всі дані транзакцій у ланцюжку. + +Доступність даних також допомагає захистити протоколи масштабування поза ланцюгом, які побудовані на базовому рівні Ethereum. Змушуючи операторів у цих ланцюжках публікувати дані транзакцій на Ethereum, будь-хто може оскаржити недійсні блоки, створюючи докази шахрайства, що посилаються на правильний стан ланцюжка. + +Ланцюжки Plasma в основному зберігають дані транзакцій в оператора та **не публікують жодних даних в основній мережі** (тобто, окрім періодичних зобов'язань щодо стану). Це означає, що користувачі повинні покладатися на оператора для надання даних блоку, якщо їм потрібно створити докази шахрайства, що оскаржують недійсні транзакції. Якщо ця система працює, користувачі завжди можуть використовувати докази шахрайства для захисту коштів. + +Проблема починається, коли оператор, а не просто будь-який користувач, є стороною, що діє зловмисно. Оскільки оператор повністю контролює блокчейн, у нього більше стимулів просувати недійсні переходи стану у великих масштабах, наприклад, красти кошти, що належать користувачам у ланцюжку Plasma. + +У цьому випадку використання класичної системи доказів шахрайства не працює. Оператор може легко здійснити недійсну транзакцію, переказавши кошти Еліс та Боба на свій гаманець, і приховати дані, необхідні для створення доказу шахрайства. Це можливо, оскільки оператор не зобов’язаний надавати дані користувачам або основній мережі. + +Тому найбільш оптимістичним рішенням є спроба «масового виходу» користувачів з ланцюжка Plasma. Масовий вихід уповільнює план зловмисного оператора щодо крадіжки коштів і забезпечує певний рівень захисту для користувачів. Запити на виведення коштів упорядковуються залежно від того, коли було створено кожен UTXO (або токен), що не дозволяє зловмисним операторам випереджати чесних користувачів. + +Тим не менш, нам все ще потрібен спосіб перевірки дійсності запитів на виведення коштів під час масового виходу — щоб запобігти тому, щоб опортуністичні особи наживалися на хаосі, обробляючи недійсні виходи. Рішення просте: вимагати від користувачів публікувати останній **дійсний стан ланцюжка**, щоб вивести свої гроші. + +Але цей підхід все ще має проблеми. Наприклад, якщо всім користувачам ланцюжка Plasma потрібно вийти (що можливо у випадку зловмисного оператора), то весь дійсний стан ланцюжка Plasma повинен бути одразу скинутий на базовий рівень Ethereum. З огляду на довільний розмір ланцюжків Plasma (висока пропускна здатність = більше даних) і обмеження швидкості обробки Ethereum, це не ідеальне рішення. + +Хоча ігри з виходом теоретично звучать добре, масові виходи в реальному житті, ймовірно, викличуть перевантаження в мережі самого Ethereum. Окрім шкоди функціональності Ethereum, погано скоординований масовий вихід означає, що користувачі можуть не мати змоги вивести кошти до того, як оператор вичерпає кожен обліковий запис у ланцюжку Plasma. + +## Переваги та недоліки Plasma {#pros-and-cons-of-plasma} + +| Переваги | Недоліки | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Пропонує високу пропускну здатність і низьку вартість транзакції. | Не підтримує загальні обчислення (не може запускати смарт-контракти). За допомогою логіки предикатів підтримуються лише базові передачі, свопи та деякі інші види транзакцій. | +| Підходить для транзакцій між користувачами (без накладних витрат на пару користувачів, якщо обидва вказані в плазмовому ланцюгу) | Необхідно періодично стежити за мережею (вимога життєдіяльності) або делегувати цю відповідальність комусь іншому, щоб забезпечити безпеку ваших коштів. | +| Ланцюги Plasma можна адаптувати до конкретних випадків використання, які не пов’язані з основним ланцюгом. Будь-хто, включаючи бізнес, може налаштувати смарт-контракти Plasma, щоб забезпечити масштабовану інфраструктуру, яка працює в різних контекстах. | Покладається на одного або декількох операторів для зберігання даних та обслуговування їх за запитом. | +| Зменшує навантаження на основну мережу Ethereum, переміщуючи обчислення та зберігання поза ланцюжком. | Зняття коштів відкладається на кілька днів, щоб урахувати проблеми. Для взаємозамінних активів це можна пом'якшити за допомогою постачальників ліквідності, але є пов'язані з цим капітальні витрати. | +| | Якщо занадто багато користувачів спробують вийти одночасно, мережа Ethereum Mainnet може перевантажитися. | + +## Plasma проти протоколів масштабування рівня 2 {#plasma-vs-layer-2} + +Хоча колись Plasma вважалася корисним рішенням для масштабування Ethereum, згодом від неї відмовилися на користь [протоколів масштабування рівня 2 (L2)](/layer-2/). Рішення для масштабування L2 усувають кілька проблем Plasma: + +### Ефективність {#efficiency} + +[Зведення з нульовим розголошенням](/developers/docs/scaling/zk-rollups) генерують криптографічні докази дійсності кожної партії транзакцій, оброблених поза ланцюжком. Це не дозволяє користувачам (та операторам) просувати недійсні переходи стану, усуваючи потребу в періодах оскарження та іграх з виходом. Це також означає, що користувачам не потрібно періодично стежити за ланцюжком, щоб захистити свої кошти. + +### Підтримка смарт-контрактів {#support-for-smart-contracts} + +Іншою проблемою фреймворку Plasma була [неможливість підтримувати виконання смарт-контрактів Ethereum](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). У результаті більшість реалізацій Plasma були створені переважно для простих платежів або обміну токенами ERC-20. + +І навпаки, оптимістичні зведення сумісні з [віртуальною машиною Ethereum](/developers/docs/evm/) і можуть запускати власні [смарт-контракти](/developers/docs/smart-contracts/) Ethereum, що робить їх корисним і _безпечним_ рішенням для масштабування [децентралізованих застосунків](/developers/docs/dapps/). Так само, розробляються плани [створити реалізацію EVM з нульовим розголошенням (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549), що дозволить ZK-зведенням обробляти довільну логіку та виконувати смарт-контракти. + +### Недоступність даних {#data-unavailability} + +Як пояснювалося раніше, Plasma страждає від проблеми доступності даних. Якщо зловмисний оператор просуне недійсний перехід у ланцюжку Plasma, користувачі не зможуть його оскаржити, оскільки оператор може приховати дані, необхідні для створення доказу шахрайства. Зведення вирішують цю проблему, змушуючи операторів розміщувати дані транзакцій на Ethereum, що дозволяє будь-кому перевіряти стан ланцюжка та створювати докази шахрайства за необхідності. + +### Проблема масового виходу {#mass-exit-problem} + +ZK-зведення та оптимістичні зведення вирішують проблему масового виходу Plasma різними способами. Наприклад, ZK-зведення покладається на криптографічні механізми, які гарантують, що оператори не можуть вкрасти кошти користувачів за жодних обставин. + +Аналогічно, оптимістичні зведення накладають період затримки на виведення коштів, протягом якого будь-хто може ініціювати оскарження та запобігти зловмисним запитам на виведення. Хоча це схоже на Plasma, різниця в тому, що верифікатори мають доступ до даних, необхідних для створення доказів шахрайства. Таким чином, користувачам зведень не потрібно брати участь у шаленій міграції «першим на вихід» до основної мережі Ethereum. + +## Чим Plasma відрізняється від сайдчейнів і шардингу? {#plasma-sidechains-sharding} + +Plasma, сайдчейни та шардінг досить схожі, оскільки всі вони певним чином підключаються до основної мережі Ethereum. Однак рівень і міцність цих зв’язків різняться, що впливає на властивості безпеки кожного рішення масштабування. + +### Plasma проти сайдчейнів {#plasma-vs-sidechains} + +[Сайдчейн](/developers/docs/scaling/sidechains/) — це незалежний блокчейн, підключений до основної мережі Ethereum через двосторонній міст. [Мости](/bridges/) дозволяють користувачам обмінюватися токенами між двома блокчейнами для здійснення транзакцій у сайдчейні, зменшуючи перевантаження основної мережі Ethereum і покращуючи масштабованість. +Сайдчейни використовують окремі механізми консенсусу і, як правило, набагато менші, ніж Mainnet Ethereum. Як наслідок, приєднання активів до цих ланцюжків пов’язане з підвищеним ризиком; враховуючи відсутність гарантій безпеки, успадкованих від основної мережі Ethereum в моделі сайдчейну, користувачі ризикують втратити кошти в результаті атаки на сайдчейн. + +І навпаки, ланцюги Plasma отримують свою безпеку від Mainnet. Це робить їх значно безпечнішими, ніж сайдчейни. І сайдчейни, і ланцюги Plasma можуть мати різні протоколи консенсусу, але різниця в тому, що Plasma ланцюги публікують корені Меркла для кожного блоку в Mainnet Ethereum. Корені блоку — це невеликі фрагменти інформації, які ми можемо використовувати для перевірки інформації про транзакції, які відбуваються в ланцюжку Plasma. Якщо відбувається атака на ланцюг Plasma, користувачі можуть безпечно виводити свої кошти назад у Mainnet, використовуючи відповідні докази. + +### Plasma проти шардингу {#plasma-vs-sharding} + +І ланцюжки Plasma, і ланцюжки шардів періодично публікують криптографічні докази в мережі Ethereum Mainnet. Проте обидва вони мають різні властивості безпеки. + +Ланцюжки шардів передають «заголовки зіставлення» в Mainnet, що містять детальну інформацію про кожен сегмент даних. Вузли в Mainnet перевіряють і забезпечують дійсність фрагментів даних, зменшуючи ймовірність недійсних переходів сегментів і захищаючи мережу від зловмисної активності. + +Plasma відрізняється тим, що Mainnet отримує лише мінімальну інформацію про стан дочірніх ланцюжків. Це означає, що Mainnet не може ефективно перевіряти транзакції, проведені в дочірніх ланцюгах, що робить їх менш безпечними. + +**Примітка**: шардинг блокчейну Ethereum більше не є частиною дорожньої карти. Його замінило масштабування за допомогою зведень та [Danksharding](/roadmap/danksharding). + +### Використовуйте Plasma {#use-plasma} + +Кілька проектів забезпечують реалізації Plasma, які ви можете інтегрувати у свої додатки: + +- [Polygon](https://polygon.technology/) (раніше Matic Network) + +## Для подальшого читання {#further-reading} + +- [Дізнайтеся про Plasma](https://www.learnplasma.org/en/) +- [Коротке нагадування про те, що означає «спільна безпека» і чому це так важливо](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [Сайдчейни проти Plasma проти шардингу](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [Розуміння Plasma, частина 1: Основи](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [Життя та смерть Plasma](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ diff --git a/public/content/translations/uk/developers/docs/scaling/sidechains/index.md b/public/content/translations/uk/developers/docs/scaling/sidechains/index.md new file mode 100644 index 00000000000..53a47b247d4 --- /dev/null +++ b/public/content/translations/uk/developers/docs/scaling/sidechains/index.md @@ -0,0 +1,73 @@ +--- +title: "Сайдчейни" +description: "Введення сайдчейнів як рішення для масштабування, яке зараз використовується спільнотою Ethereum." +lang: uk +sidebarDepth: 3 +--- + +Сайдчейн — це окремий блокчейн, який працює незалежно від Ethereum і з'єднаний з головною мережею Ethereum за допомогою двостороннього моста. Сайдчейни можуть мати окремі параметри блоків та [алгоритми консенсусу](/developers/docs/consensus-mechanisms/), які часто розробляються для ефективної обробки транзакцій. Проте використання сайдчейну пов’язане з компромісами, оскільки вони не успадковують властивості безпеки Ethereum. На відміну від [рішень для масштабування на шарі 2](/layer-2/), сайдчейни не публікують зміни стану та дані транзакцій назад у головну мережу Ethereum. + +Сайдчейни також певною мірою жертвують децентралізацією або безпекою для досягнення високої пропускної здатності ([трилема масштабованості](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Проте Ethereum прагне до масштабування без шкоди для децентралізації та безпеки. + +## Як працюють сайдчейни? {#how-do-sidechains-work} + +Сайдчейни — це незалежні блокчейни з різними історіями, планами розвитку та особливостями проєктування. Хоча сайдчейн може мати деякі поверхневі подібності з Ethereum, він має кілька відмінних рис. + +### Алгоритми консенсусу {#consensus-algorithms} + +Однією з якостей, що робить сайдчейни унікальними (тобто відмінними від Ethereum), є використовуваний алгоритм консенсусу. Сайдчейни не покладаються на Ethereum для досягнення консенсусу і можуть обирати альтернативні протоколи консенсусу, що відповідають їхнім потребам. Деякі приклади алгоритмів консенсусу, що використовуються в сайдчейнах: + +- [Доказ повноважень](/developers/docs/consensus-mechanisms/poa/) +- [Делегований доказ частки](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [Візантійська відмовостійкість](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained). + +Як і Ethereum, сайдчейни мають вузли-валідатори, які перевіряють та обробляють транзакції, створюють блоки та зберігають стан блокчейну. Валідатори також відповідають за підтримку консенсусу в мережі та її захист від зловмисних атак. + +#### Параметри блоку {#block-parameters} + +Ethereum встановлює обмеження на [час створення блоку](/developers/docs/blocks/#block-time) (тобто час, необхідний для створення нових блоків) і [розмір блоку](/developers/docs/blocks/#block-size) (тобто обсяг даних, що містяться в одному блоці, виражений у газі). Навпаки, сайдчейни часто використовують інші параметри, як-от швидший час створення блоків і вищі ліміти газу, щоб досягти високої пропускної здатності, швидких транзакцій і низьких комісій. + +Хоча це має певні переваги, це має критичні наслідки для децентралізації та безпеки мережі. Параметри блоків, як-от швидкий час їх створення та великі розміри, ускладнюють запуск повного вузла, у результаті чого лише кілька \"супервузлів\" відповідають за безпеку ланцюга. У такому сценарії зростає ймовірність змови валідаторів або зловмисного захоплення ланцюга. + +Щоб блокчейни масштабувалися без шкоди для децентралізації, запуск вузла має бути доступним для всіх, а не лише для сторін зі спеціалізованим обладнанням. Ось чому докладаються зусилля, щоб кожен міг [запустити повний вузол](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) у мережі Ethereum. + +### Сумісність з EVM {#evm-compatibility} + +Деякі сайдчейни сумісні з EVM і можуть виконувати контракти, розроблені для [Віртуальної машини Ethereum (EVM)](/developers/docs/evm/). Сумісні з EVM сайдчейни підтримують смарт-контракти, [написані на Solidity](/developers/docs/smart-contracts/languages/), а також інші мови смарт-контрактів EVM. Це означає, що смарт-контракти, написані для головної мережі Ethereum, також працюватимуть на сумісних з EVM сайдчейнах. + +Це означає, що якщо ви хочете використовувати свій [dApp](/developers/docs/dapps/) у сайдчейні, це лише питання розгортання вашого [смарт-контракту](/developers/docs/smart-contracts/) в цьому сайдчейні. Він виглядає, відчувається і діє так само, як і головна мережа — ви пишете контракти на Solidity і взаємодієте з ланцюгом через RPC сайдчейну. + +Оскільки сайдчейни сумісні з EVM, вони вважаються корисним [рішенням для масштабування](/developers/docs/scaling/) для нативних dApps для Ethereum. З вашим dApp у сайдчейні користувачі можуть насолоджуватися нижчими комісіями за газ і швидшими транзакціями, особливо якщо головна мережа перевантажена. + +Однак, як пояснювалося раніше, використання сайдчейну пов’язане зі значними компромісами. Кожен сайдчейн відповідає за власну безпеку й не успадковує властивості безпеки Ethereum. Це підвищує ймовірність зловмисної поведінки, яка може вплинути на ваших користувачів або поставити під загрозу їхні кошти. + +### Переміщення активів {#asset-movement} + +Для того щоб окремий блокчейн став сайдчейном для головної мережі Ethereum, він повинен мати можливість забезпечувати переказ активів з головної мережі Ethereum і назад. Ця взаємосумісність з Ethereum досягається за допомогою блокчейн-моста. [Мости](/bridges/) використовують смарт-контракти, розгорнуті в головній мережі Ethereum і сайдчейні, для контролю за переміщенням коштів між ними. + +Хоча мости допомагають користувачам переміщувати кошти між Ethereum і сайдчейном, активи фізично не переміщуються між двома ланцюгами. Натомість для передачі цінності між ланцюгами використовуються механізми, які зазвичай включають карбування та спалювання. Докладніше про те, [як працюють мости](/developers/docs/bridges/#how-do-bridges-work). + +## Переваги та недоліки сайдчейнів {#pros-and-cons-of-sidechains} + +| Переваги | Недоліки | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Технологія, що лежить в основі сайдчейнів, добре налагоджена та виграє від обширних досліджень і вдосконалень у дизайні. | Сайдчейни певною мірою жертвують децентралізацією та відсутністю потреби в довірі заради масштабованості. | +| Сайдчейни підтримують загальні обчислення та пропонують сумісність із EVM (вони можуть запускати нативні dApps для Ethereum). | Сайдчейн використовує окремий механізм консенсусу і не успадковує гарантії безпеки Ethereum. | +| Сайдчейни використовують різні моделі консенсусу для ефективної обробки транзакцій та зниження комісій для користувачів. | Сайдчейни вимагають вищих припущень щодо довіри (наприклад, кворум зловмисних валідаторів сайдчейну може вчинити шахрайство). | +| Сумісні з EVM сайдчейни дозволяють dApps розширювати свою екосистему. | | + +### Використання сайдчейнів {#use-sidechains} + +Кілька проєктів забезпечують реалізації сайдчейнів, які ви можете інтегрувати у свої додатки: + +- [Polygon PoS](https://polygon.technology/solutions/polygon-pos) +- [Skale](https://skale.network/) +- [Gnosis Chain (раніше xDai)](https://www.gnosischain.com/) +- [Loom Network](https://loomx.io/) +- [Metis Andromeda](https://www.metis.io/) + +## Для подальшого читання {#further-reading} + +- [Масштабування dApps Ethereum за допомогою сайдчейнів](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _8 лютого 2018 р. – Георгіос Константинопулос_ + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ From 006aa47daceb4c1b3bf10dd8af2ab33a9975ead7 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 17:42:54 +0000 Subject: [PATCH 2/2] fix(i18n): restore English comments in Solidity code block Crowdin translated inline comments inside a Solidity code fence in the Ukrainian oracles page. Code comments should stay in English to avoid confusing developers following the examples. --- .../uk/developers/docs/oracles/index.md | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/public/content/translations/uk/developers/docs/oracles/index.md b/public/content/translations/uk/developers/docs/oracles/index.md index 65347bbbde3..06db5470063 100644 --- a/public/content/translations/uk/developers/docs/oracles/index.md +++ b/public/content/translations/uk/developers/docs/oracles/index.md @@ -88,29 +88,29 @@ lang: uk pragma solidity >=0.4.21 <0.6.0; contract Oracle { - Request[] requests; //список запитів, зроблених до контракту - uint currentId = 0; //збільшення ідентифікатора запиту - uint minQuorum = 2; //мінімальна кількість відповідей, яку потрібно отримати, перш ніж оголосити остаточний результат - uint totalOracleCount = 3; //Жорстко закодована кількість оракулів + Request[] requests; //list of requests made to the contract + uint currentId = 0; //increasing request id + uint minQuorum = 2; //minimum number of responses to receive before declaring final result + uint totalOracleCount = 3; // Hardcoded oracle count - // визначає загальний запит до API + // defines a general api request struct Request { - uint id; //ідентифікатор запиту - string urlToQuery; //URL-адреса API - string attributeToFetch; //атрибут json (ключ), який потрібно отримати у відповіді - string agreedValue; //значення з ключа - mapping(uint => string) answers; //відповіді, надані оракулами - mapping(address => uint) quorum; //оракули, які запитуватимуть відповідь (1=оракул не проголосував, 2=оракул проголосував) + uint id; //request id + string urlToQuery; //API url + string attributeToFetch; //json attribute (key) to retrieve in the response + string agreedValue; //value from key + mapping(uint => string) answers; //answers provided by the oracles + mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted) } - //подія, яка запускає оракула за межами блокчейну + //event that triggers oracle outside of the blockchain event NewRequest ( uint id, string urlToQuery, string attributeToFetch ); - //спрацьовує, коли є консенсус щодо остаточного результату + //triggered when there's a consensus on the final result event UpdatedRequest ( uint id, string urlToQuery, @@ -127,23 +127,23 @@ contract Oracle { uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); Request storage r = requests[length-1]; - // Жорстко закодовані адреси оракулів + // Hardcoded oracles address r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; - // запустити подію, яку має виявити оракул за межами блокчейну + // launch an event to be detected by oracle outside of blockchain emit NewRequest ( currentId, _urlToQuery, _attributeToFetch ); - // збільшити ідентифікатор запиту + // increase request id currentId++; } - //викликається оракулом для запису своєї відповіді + //called by the oracle to record its answer function updateRequest ( uint _id, string memory _valueRetrieved @@ -151,18 +151,18 @@ contract Oracle { Request storage currRequest = requests[_id]; - //перевірити, чи є оракул у списку довірених оракулів - //і чи оракул ще не проголосував + //check if oracle is in the list of trusted oracles + //and if the oracle hasn't voted yet if(currRequest.quorum[address(msg.sender)] == 1){ - //позначка, що ця адреса проголосувала + //marking that this address has voted currRequest.quorum[msg.sender] = 2; - //перебір «масиву» відповідей, доки позиція не звільниться, і збереження отриманого значення + //iterate through "array" of answers until a position if free and save the retrieved value uint tmpI = 0; bool found = false; while(!found) { - //знайти перший порожній слот + //find first empty slot if(bytes(currRequest.answers[tmpI]).length == 0){ found = true; currRequest.answers[tmpI] = _valueRetrieved; @@ -172,8 +172,8 @@ contract Oracle { uint currentQuorum = 0; - //перебір списку оракулів і перевірка, чи достатньо оракулів (мінімальний кворум) - //проголосували за ту саму відповідь, що й поточна + //iterate through oracle list and check if enough oracles(minimum quorum) + //have voted the same answer as the current one for(uint i = 0; i < totalOracleCount; i++){ bytes memory a = bytes(currRequest.answers[i]); bytes memory b = bytes(_valueRetrieved);