diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/poa/index.md new file mode 100644 index 00000000000..47eb919fd71 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/poa/index.md @@ -0,0 +1,80 @@ +--- +title: "Доказ повноважень (PoA)" +description: "Пояснення протоколу консенсусу доказу повноважень (proof-of-authority) та його ролі в екосистемі блокчейну." +lang: uk +--- + +**Доказ повноважень (PoA)** — це алгоритм консенсусу на основі репутації, який є модифікованою версією [доказу частки](/developers/docs/consensus-mechanisms/pos/). Він здебільшого використовується приватними ланцюжками, тестнетами та локальними мережами розробки. PoA — це алгоритм консенсусу на основі репутації, який вимагає довіри до набору авторизованих підписувачів для створення блоків, на відміну від механізму на основі частки в PoS. + +## Передумови {#prerequisites} + +Щоб краще зрозуміти цю сторінку, рекомендуємо спочатку ознайомитися з [транзакціями](/developers/docs/transactions/), [блоками](/developers/docs/blocks/) та [механізмами консенсусу](/developers/docs/consensus-mechanisms/). + +## Що таке доказ повноважень (PoA)? {#what-is-poa} + +Доказ повноважень — це модифікована версія **[доказу частки](/developers/docs/consensus-mechanisms/pos/) (PoS)**, що є алгоритмом консенсусу на основі репутації, а не механізмом на основі частки, як у PoS. Цей термін був вперше представлений у 2017 році Гевіном Вудом, і цей алгоритм консенсусу в основному використовувався приватними ланцюжками, тестнетами та локальними мережами розробки, оскільки він долає потребу у високоякісних ресурсах, як це робить PoW, та долає проблеми масштабованості PoS, маючи невелику підмножину вузлів, що зберігають блокчейн і створюють блоки. + +Доказ повноважень вимагає довіри до набору авторизованих підписувачів, які визначені в [генезис-блоці](/glossary/#genesis-block). У більшості поточних реалізацій усі авторизовані підписувачі зберігають рівні повноваження та привілеї при визначенні консенсусу ланцюжка. Ідея стейкінгу на основі репутації полягає в тому, що кожен авторизований валідатор добре відомий усім через такі речі, як «знай свого клієнта» (KYC), або завдяки тому, що відома організація є єдиним валідатором — таким чином, якщо валідатор робить щось не так, його особу встановлено. + +Існує кілька реалізацій PoA, але стандартна реалізація Ethereum — це **clique**, яка реалізує [EIP-225](https://eips.ethereum.org/EIPS/eip-225). Clique — це дружній до розробників і простий у реалізації стандарт, що підтримує всі типи синхронізації клієнтів. Інші реалізації включають [IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) та [Aura](https://openethereum.github.io/Chain-specification). + +## Як це працює {#how-it-works} + +У PoA для створення нових блоків вибирається набір авторизованих підписувачів. Підписувачі вибираються на основі їхньої репутації, і тільки вони мають право створювати нові блоки. Підписувачі вибираються за циклічним принципом (round-robin), і кожен підписувач може створити блок у певному часовому проміжку. Час створення блоку є фіксованим, і підписувачі повинні створити блок протягом цього часового проміжку. + +Репутація в цьому контексті — це не кількісно вимірювана річ, а скоріше репутація відомих корпорацій, таких як Microsoft і Google. Отже, спосіб вибору довірених підписувачів не є алгоритмічним, а є звичайним людським актом _довіри_, коли суб'єкт, скажімо, наприклад, Microsoft, створює приватну мережу PoA між сотнями або тисячами стартапів і сам виступає в ролі єдиного довіреного підписувача з можливістю додавання в майбутньому інших відомих підписувачів, таких як Google. Стартапи, без сумніву, довірятимуть Microsoft, що вона завжди діятиме чесно, і використовуватимуть мережу. Це вирішує потребу в стейкінгу в різних невеликих/приватних мережах, які були створені для різних цілей, щоб підтримувати їхню децентралізацію та функціонування, а також потребу в майнерах, що споживає багато енергії та ресурсів. Деякі приватні мережі використовують стандарт PoA, як-от VeChain, а деякі модифікують його, як-от Binance, яка використовує [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa), що є спеціальною модифікованою версією PoA та PoS. + +Процес голосування здійснюється самими підписувачами. Кожен підписувач голосує за додавання або видалення підписувача у своєму блоці, коли створює новий блок. Вузли підраховують голоси, і підписувачі додаються або видаляються на основі досягнення голосами певного порогу `SIGNER_LIMIT`. + +Може виникнути ситуація, коли відбуваються невеликі форки; складність блоку залежить від того, чи був блок підписаний у свою чергу чи позачергово. Блоки, підписані «у свою чергу», мають складність 2, а блоки, підписані «позачергово», мають складність 1. У разі невеликих форків ланцюжок, у якому більшість підписувачів запечатують блоки «у свою чергу», накопичить найбільшу складність і переможе. + +## Вектори атак {#attack-vectors} + +### Зловмисні підписувачі {#malicious-signers} + +Зловмисник може бути доданий до списку підписувачів, або ключ/машина для підпису може бути скомпрометована. У такому сценарії протокол повинен мати можливість захистити себе від реорганізацій та спаму. Запропоноване рішення полягає в тому, що за наявності списку з N авторизованих підписувачів будь-який підписувач може викарбувати лише 1 блок з кожних K. Це гарантує, що шкода буде обмежена, а решта валідаторів зможе виключити зловмисника шляхом голосування. + +### Цензура {#censorship-attack} + +Ще один цікавий вектор атаки — це коли підписувач (або група підписувачів) намагається цензурувати блоки, які містять голоси за їх видалення зі списку авторизації. Щоб обійти це, дозволена частота карбування блоків для підписувачів обмежується до 1 з N/2. Це гарантує, що зловмисним підписувачам потрібно контролювати щонайменше 51% облікових записів для підпису, після чого вони фактично стануть новим джерелом істини для ланцюжка. + +### Спам {#spam-attack} + +Ще один невеликий вектор атаки — це коли зловмисні підписувачі вставляють нові пропозиції для голосування в кожен блок, який вони карбують. Оскільки вузлам потрібно підраховувати всі голоси для створення фактичного списку авторизованих підписувачів, вони повинні реєструвати всі голоси з часом. Без встановлення обмеження на вікно голосування, це може зростати повільно, але безмежно. Рішення полягає у встановленні _рухомого_ вікна з W блоків, після якого голоси вважаються застарілими. _Розумним вікном може бути 1-2 епохи._ + +### Одночасні блоки {#concurrent-blocks} + +У мережі PoA, коли є N авторизованих підписувачів, кожному підписувачу дозволено карбувати 1 блок з K, що означає, що N-K+1 валідаторів можуть карбувати в будь-який момент часу. Щоб запобігти змаганню цих валідаторів за блоки, кожен підписувач повинен додати невелике випадкове «зміщення» до часу випуску нового блоку. Хоча цей процес гарантує, що невеликі форки трапляються рідко, випадкові форки все ще можуть відбуватися, як і в основній мережі. Якщо буде виявлено, що підписувач зловживає своїми повноваженнями та спричиняє хаос, інші підписувачі можуть виключити його шляхом голосування. + +Якщо, наприклад, є 10 авторизованих підписувачів і кожному підписувачу дозволено створювати 1 блок з 20, то в будь-який момент часу 11 валідаторів можуть створювати блоки. Щоб вони не змагалися за створення блоків, кожен підписувач додає невелике випадкове «зміщення» до часу випуску нового блоку. Це зменшує виникнення невеликих форків, але все ще допускає випадкові форки, як це спостерігається в основній мережі Ethereum. Якщо підписувач зловживає своїми повноваженнями та спричиняє збої, його можуть виключити з мережі шляхом голосування. + +## Переваги та недоліки {#pros-and-cons} + +| Переваги | Недоліки | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Масштабованість вища, ніж у інших популярних механізмів, таких як PoS та PoW, оскільки він базується на обмеженій кількості підписувачів блоків | Мережі PoA зазвичай мають відносно невелику кількість валідуючих вузлів. Це робить мережу PoA більш централізованою. | +| Блокчейни PoA неймовірно дешеві в експлуатації та обслуговуванні | Стати авторизованим підписувачем зазвичай недоступно для звичайної людини, оскільки блокчейн вимагає наявності суб’єктів із усталеною репутацією. | +| Транзакції підтверджуються дуже швидко, час може становити менше 1 секунди, оскільки для валідації нових блоків потрібна лише обмежена кількість підписувачів | Зловмисні підписувачі можуть здійснювати реорганізацію, подвійні витрати, цензурувати транзакції в мережі; ці атаки пом’якшені, але все ще можливі | + +## Для подальшого читання {#further-reading} + +- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _стандарт Clique_ +- [Дослідження доказу повноважень](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Криптоекономіка_ +- [Що таке доказ повноважень](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_ +- [Пояснення доказу повноважень](https://academy.binance.com/en/articles/proof-of-authority-explained) _Binance_ +- [PoA у блокчейні](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba) +- [Пояснення Clique](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d) +- [Застаріла специфікація PoA, Aura](https://openethereum.github.io/Chain-specification) +- [IBFT 2.0, ще одна реалізація PoA](https://besu.hyperledger.org/private-networks/concepts/poa) + +### Цікавить наочний матеріал? Для тих, хто навчається візуально {#visual-learner} + +Перегляньте візуальне пояснення доказу повноважень: + + + +## Пов'язані теми {#related-topics} + +- [Підтвердження роботи](/developers/docs/consensus-mechanisms/pow/) +- [Доказ частки](/developers/docs/consensus-mechanisms/pos/) + diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md new file mode 100644 index 00000000000..ccc9d01eaef --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -0,0 +1,166 @@ +--- +title: "Атаки на доказ частки Ethereum та захист" +description: "Дізнайтеся про відомі вектори атак на криптовалюту Ethereum з підтвердженням частки і способи захисту від них." +lang: uk +--- + +Злодії і хакери постійно шукають можливості атакувати клієнтське програмне забезпечення Ethereum. На цій сторінці описані відомі вектори атак на рівень консенсусу Ethereum і способи захисту від них. Інформація на цій сторінці адаптована з [довшої версії](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs). + +## Передумови {#prerequisites} + +Потрібні деякі базові знання про доказ частки або [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Також буде корисно мати базове розуміння [рівня заохочень](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) Ethereum і його алгоритму вибору форку [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper). + +## Чого хочуть зловмисники? {#what-do-attackers-want} + +Поширеною помилкою є те, що успішний зловмисник може генерувати новий ефіріум або викачувати ефіріум з довільних акаунтів. Жоден із цих варіантів неможливий, оскільки всі транзакції виконуються всіма клієнтами виконання в мережі. Вони повинні задовольняти базові умови дійсності (наприклад, транзакції підписані приватним ключем відправника, у відправника достатній баланс тощо), інакше вони просто скасовуються. Існує три класи результатів, яких зловмисник може реально прагнути: реорганізації, подвійна фіналізація або затримка фіналізації. + +**Реорганізація** — це перетасування блоків у новому порядку, можливо, з додаванням або видаленням деяких блоків у канонічному ланцюжку. Зловмисна реорганізація може забезпечити включення або виключення певних блоків, що дає змогу подвійно витрачати кошти або витягувати цінність шляхом випереджальних і подальших транзакцій (MEV). Реорганізації також можуть використовуватися для запобігання включенню певних транзакцій до канонічного ланцюжка — це форма цензури. Найбільш екстремальною формою реорганізації є «скасування фіналізації», яке видаляє або замінює блоки, які раніше були фіналізовані. Це можливо, лише якщо зловмисник знищить понад ⅓ усього поставленого ефіру — ця гарантія відома як «економічна фіналізація» — докладніше про це пізніше. + +**Подвійна фіналізація** — це малоймовірний, але серйозний стан, за якого два форки можуть бути фіналізовані одночасно, створюючи постійний розкол у ланцюжку. Теоретично це можливо для зловмисника, який готовий ризикнути 34 % загального обсягу ефіру в стейкінгу. Спільнота буде змушена координувати свої дії поза ланцюгом і дійти згоди щодо того, якого ланцюжка дотримуватися, що вимагатиме міцності соціального рівня. + +Атака **затримки фіналізації** не дає мережі досягти умов, необхідних для фіналізації розділів ланцюжка. Без фіналізації важко довіряти фінансовим застосункам, створеним на базі Ethereum. Метою атаки із затримкою фіналізації, найімовірніше, є просто збій роботи Ethereum, а не отримання прямого прибутку, якщо тільки зловмисник не має якоїсь стратегічної короткої позиції (позицій). + +Атака на соціальний рівень може мати на меті підрив суспільної довіри до Ethereum, знецінення ефіру, зменшення впровадження або ослаблення спільноти Ethereum, щоб ускладнити позасмугову координацію. + +З’ясувавши, чому зловмисник може атакувати Ethereum, у наступних розділах розглянемо, _як_ він може це зробити. + +## Методи атаки {#methods-of-attack} + +### Атаки рівня 0 {#layer-0} + +По-перше, особи, які не беруть активної участі в роботі Ethereum (шляхом запуску клієнтського програмного забезпечення), можуть атакувати соціальний рівень (рівень 0). Рівень 0 — це фундамент, на якому побудовано Ethereum, і тому він є потенційною поверхнею для атак, наслідки яких поширюються на решту стека. Деякі приклади можуть включати: + +- Кампанія з дезінформації може підірвати довіру спільноти до дорожньої карти Ethereum, команд розробників, застосунків тощо. Це, своєю чергою, може зменшити кількість осіб, які бажають брати участь у забезпеченні безпеки мережі, погіршуючи як децентралізацію, так і крипто-економічну безпеку. + +- Цілеспрямовані атаки та/або залякування, спрямовані на спільноту розробників. Це може призвести до добровільного виходу розробників і сповільнити прогрес Ethereum. + +- Надмірно завзяте регулювання також можна розглядати як атаку на рівень 0, оскільки воно може швидко дестимулювати участь і впровадження. + +- Проникнення в спільноту розробників обізнаних, але зловмисних суб’єктів, метою яких є сповільнення прогресу шляхом обговорення незначних питань, затримки ключових рішень, створення спаму тощо. + +- Підкуп ключових гравців в екосистемі Ethereum з метою впливу на прийняття рішень. + +Що робить ці атаки особливо небезпечними, так це те, що в багатьох випадках потрібен дуже малий капітал або технічні знання. Атака рівня 0 може посилити крипто-економічну атаку. Наприклад, якщо цензура або скасування фіналізації були досягнуті зловмисним мажоритарним стейкхолдером, підрив соціального рівня може ускладнити координацію відповіді спільноти поза смугою. + +Захист від атак рівня 0, ймовірно, не є простим, але можна встановити деякі основні принципи. Одним із них є підтримка високого співвідношення сигнал/шум для публічної інформації про Ethereum, що створюється та поширюється чесними членами спільноти через блоги, сервери Discord, анотовані специфікації, книги, подкасти та Youtube. Тут, на ethereum.org, ми докладаємо всіх зусиль, щоб підтримувати точність інформації та перекладати її якомога більшою кількістю мов. Заповнення простору високоякісною інформацією та мемами є ефективним захистом від дезінформації. + +Ще одним важливим укріпленням проти атак соціального рівня є чітка місія та протокол управління. Ethereum позиціонує себе як чемпіон децентралізації та безпеки серед смарт-контрактів рівня 1, водночас високо цінуючи масштабованість і стійкість. Незалежно від розбіжностей, що виникають у спільноті Ethereum, ці основні принципи мінімально скомпрометовані. Оцінка наративу на відповідність цим основним принципам і їх розгляд через послідовні раунди перевірки в процесі EIP (пропозиція щодо покращення Ethereum), може допомогти спільноті відрізнити добросовісних учасників від зловмисних і обмежує можливості зловмисників впливати на майбутній напрямок розвитку Ethereum. + +Нарешті, вкрай важливо, щоб спільнота Ethereum залишалася відкритою та привітною для всіх учасників. Спільнота з «охоронцями» та ексклюзивністю особливо вразлива до соціальних атак, оскільки легко створювати наративи «ми і вони». Трайбалізм і токсичний максималізм шкодять спільноті та руйнують безпеку рівня 0. Ефіріанці, які зацікавлені в безпеці мережі, повинні розглядати свою поведінку в Інтернеті та в реальному світі як прямий внесок у безпеку рівня 0 Ethereum. + +### Атака на протокол {#attacking-the-protocol} + +Будь-хто може запустити клієнтське програмне забезпечення Ethereum. Щоб додати валідатор до клієнта, користувач повинен внести в стейкінг 32 ефіри в депозитний контракт. Валідатор дає змогу користувачеві брати активну участь у забезпеченні безпеки мережі Ethereum, пропонуючи та підтверджуючи нові блоки. Тепер валідатор має голос, який він може використовувати, щоб впливати на майбутній вміст блокчейну — він може робити це чесно та збільшувати свої запаси ефіру за допомогою винагород, або він може спробувати маніпулювати процесом у своїх інтересах, ризикуючи своєю часткою. Один зі способів здійснити атаку — це накопичити більшу частку загальної ставки, а потім використовувати її, щоб переголосувати чесних валідаторів. Чим більша частка ставки, яку контролює зловмисник, тим більша його сила голосу, особливо на певних економічних етапах, які ми розглянемо пізніше. Однак більшість зловмисників не зможуть накопичити достатньо ефіру для такої атаки, тому замість цього їм доводиться використовувати тонкі методи, щоб змусити чесну більшість діяти певним чином. + +По суті, усі атаки з невеликою часткою є тонкими варіаціями двох типів неправильної поведінки валідатора: недостатня активність (невдала атестація/пропозиція або запізнення) або надмірна активність (занадто багато пропозицій/атестацій у слоті). У своїх найпростіших формах ці дії легко обробляються алгоритмом вибору форку та рівнем стимулювання, але існують розумні способи обіграти систему на користь зловмисника. + +### Атаки з використанням невеликих сум ETH {#attacks-by-small-stakeholders} + +#### Реорганізації {#reorgs} + +У кількох статтях пояснюються атаки на Ethereum, які досягають реорганізації або затримки фіналізації лише з невеликою часткою загального поставленого ефіру. Ці атаки зазвичай покладаються на те, що зловмисник приховує певну інформацію від інших валідаторів, а потім випускає її певним нюансованим способом та/або у сприятливий момент. Зазвичай вони прагнуть витіснити деякі чесні блоки з канонічного ланцюжка. [Neuder та ін., 2020](https://arxiv.org/pdf/2102.02247.pdf) показали, як атакуючий валідатор може створити та атестувати блок (`B`) для певного слота `n+1`, але утриматися від його поширення іншим вузлам у мережі. Натомість вони утримують цей атестований блок до наступного слота `n+2`. Чесний валідатор пропонує блок (`C`) для слота `n+2`. Майже одночасно зловмисник може випустити свій прихований блок (`B`) і свої приховані атестації для нього, а також атестувати, що `B` є головою ланцюжка своїми голосами за слот `n+2`, фактично заперечуючи існування чесного блоку `C`. Коли випускається чесний блок `D`, алгоритм вибору форка бачить, що `D`, побудований на `B`, є «важчим», ніж `D`, побудований на `C`. Таким чином, зловмисник зумів видалити чесний блок `C` у слоті `n+2` з канонічного ланцюжка, використовуючи реорганізацію одного блоку ex ante. [Зловмисник із 34 %](https://www.youtube.com/watch?v=6vzXwwk12ZE) частки має дуже хороші шанси на успіх у цій атаці, як пояснюється [в цій примітці](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Теоретично, однак, цю атаку можна спробувати з меншими частками. [Neuder та ін., 2020](https://arxiv.org/pdf/2102.02247.pdf) описали, що ця атака працює з 30-відсотковою часткою, але пізніше було показано, що вона життєздатна з [2 % від загальної частки](https://arxiv.org/pdf/2009.04987.pdf) і потім знову для [одного валідатора](https://arxiv.org/abs/2110.10086#) з використанням методів балансування, які ми розглянемо в наступному розділі. + +![реорганізація ex-ante](reorg-schematic.png) + +Концептуальна схема атаки з реорганізацією одного блоку, описана вище (адаптовано з https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) + +Більш складна атака може розділити набір чесних валідаторів на окремі групи, які мають різні погляди на голову ланцюжка. Це відомо як **атака балансування**. Зловмисник чекає своєї нагоди запропонувати блок, і коли вона настає, він висловлюється неоднозначно та пропонує два. Вони надсилають один блок половині набору чесних валідаторів, а інший блок — іншій половині. Неоднозначність буде виявлена алгоритмом вибору форку, а ініціатор блоку буде покараний слешингом і виключений з мережі, але два блоки все одно існуватимуть, і приблизно половина набору валідаторів буде атестувати кожен форк. Тим часом зловмисні валідатори, що залишилися, утримують свої атестації. Потім, вибірково випускаючи атестації на користь того чи іншого форку для достатньої кількості валідаторів саме тоді, коли виконується алгоритм вибору форку, вони схиляють накопичену вагу атестацій на користь того чи іншого форку. Це може тривати нескінченно довго, причому атакуючі валідатори підтримують рівний розподіл валідаторів між двома форками. Оскільки жоден форк не може залучити 2/3 супербільшості, мережа не буде фіналізована. + +**Атаки відбиття** є схожими. Голоси знову утримуються атакуючими валідаторами. Замість того, щоб віддавати голоси для підтримки рівного розподілу між двома форками, вони використовують свої голоси у сприятливі моменти для обґрунтування контрольних точок, які чергуються між форком A та форком B. Це перемикання обґрунтування між двома форками не дає змоги створити пари обґрунтованих вихідних і цільових контрольних точок, які можна було б фіналізувати в будь-якому ланцюжку, що зупиняє фіналізацію. + + + +І атаки відбиття, і атаки балансування залежать від того, чи має зловмисник дуже точний контроль над часом передачі повідомлень у мережі, що малоймовірно. Проте в протокол вбудовані засоби захисту у вигляді додаткового зважування, яке надається швидким повідомленням порівняно з повільними. Це відомо як [посилення ваги ініціатора](https://github.com/ethereum/consensus-specs/pull/2730). Для захисту від атак відбиття алгоритм вибору форку було оновлено таким чином, щоб остання обґрунтована контрольна точка могла переключитися на контрольну точку альтернативного ланцюжка лише протягом [першої 1/3 слотів у кожній епосі](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114). Ця умова не дає зловмиснику змоги накопичувати голоси для подальшого розгортання — алгоритм вибору форку просто залишається вірним контрольній точці, яку він вибрав у першій 1/3 епохи, протягом якої проголосувала б більшість чесних валідаторів. + +У сукупності ці заходи створюють сценарій, за якого чесний ініціатор блоку випускає свій блок дуже швидко після початку слоту, потім настає період ~1/3 слота (4 секунди), коли цей новий блок може змусити алгоритм вибору форку переключитися на інший ланцюжок. Після закінчення цього ж терміну атестації, що надходять від повільних валідаторів, мають меншу вагу, ніж ті, що надійшли раніше. Це значною мірою сприяє швидким ініціаторам і валідаторам у визначенні голови ланцюжка та суттєво зменшує ймовірність успішної атаки балансування або відбиття. + +Варто зазначити, що саме по собі посилення ініціатора захищає лише від «дешевих реорганізацій», тобто тих, які намагається здійснити зловмисник з невеликою часткою. Насправді, саме посилення ініціатора може бути обіграно більшими стейкхолдерами. Автори [цієї публікації](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) описують, як зловмисник із 7-відсотковою часткою може стратегічно розгорнути свої голоси, щоб обманом змусити чесних валідаторів будувати свій форк, реорганізувавши чесний блок. Цю атаку було розроблено за припущення ідеальних умов затримки, які є дуже малоймовірними. Шанси зловмисника все ще дуже малі, а більша частка також означає більший капітал під ризиком і сильніший економічний дестимул. + +Також було запропоновано [атаку балансування, спеціально спрямовану на правило LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), яка, як припускалося, є життєздатною, незважаючи на посилення ініціатора. Зловмисник створює два конкуруючі ланцюжки, неоднозначно висловлюючи свою пропозицію блоку та поширюючи кожен блок приблизно на половину мережі, встановлюючи приблизний баланс між форками. Потім валідатори-змовники неоднозначно висловлюють свої голоси, розраховуючи час таким чином, щоб половина мережі спочатку отримала їхні голоси за форк `A`, а інша половина — спочатку за форк `B`. Оскільки правило LMD відкидає другу атестацію і зберігає лише першу для кожного валідатора, половина мережі бачить голоси за `A` і жодного за `B`, а інша половина бачить голоси за `B` і жодного за `A`. Автори описують, що правило LMD дає супротивнику «виняткову силу» для здійснення атаки балансування. + +Цей вектор атаки LMD було закрито шляхом [оновлення алгоритму вибору форку](https://github.com/ethereum/consensus-specs/pull/2845), щоб він повністю відкидав неоднозначних валідаторів з розгляду вибору форку. Алгоритм вибору форку також знижує майбутній вплив неоднозначних валідаторів. Це запобігає описаній вище атаці балансування, а також підтримує стійкість до лавинних атак. + +[**Лавинні атаки**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) — ще один клас атак, описаний у [статті від березня 2022 року](https://arxiv.org/pdf/2203.01315.pdf). Щоб здійснити лавинну атаку, зловмиснику необхідно контролювати кількох послідовних ініціаторів блоків. У кожному зі слотів пропозиції блоку зловмисник приховує свій блок, збираючи їх доти, доки чесний ланцюжок не досягне рівної ваги піддерева з прихованими блоками. Потім приховані блоки випускаються таким чином, щоб вони були максимально неоднозначними. Автори припускають, що посилення ініціатора — основний захист від атак балансування та відбиття — не захищає від деяких варіантів лавинної атаки. Однак автори також продемонстрували атаку лише на дуже ідеалізованій версії алгоритму вибору форку Ethereum (вони використовували GHOST без LMD). + +Лавинна атака пом’якшується частиною LMD алгоритму вибору форку LMD-GHOST. LMD означає «керований останнім повідомленням» і стосується таблиці, яку веде кожен валідатор і яка містить останнє повідомлення, отримане від інших валідаторів. Це поле оновлюється, лише якщо нове повідомлення надходить з пізнішого слота, ніж той, що вже є в таблиці для певного валідатора. На практиці це означає, що в кожному слоті приймається перше отримане повідомлення, а будь-які додаткові повідомлення є неоднозначними і ігноруються. Інакше кажучи, клієнти консенсусу не враховують неоднозначності — вони використовують перше повідомлення від кожного валідатора, а неоднозначності просто відкидаються, запобігаючи лавинним атакам. + +Існує кілька інших потенційних майбутніх оновлень правила вибору форку, які можуть додати до безпеки, що забезпечується посиленням ініціатора. Одним із них є [злиття переглядів (view-merge)](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), де атестувальники заморожують свій погляд на вибір форку за `n` секунд до початку слоту, а ініціатор потім допомагає синхронізувати погляд на ланцюжок у мережі. Ще одним потенційним оновленням є [фіналізація одного слота](https://notes.ethereum.org/@vbuterin/single_slot_finality), яка захищає від атак, заснованих на часі передачі повідомлень, фіналізуючи ланцюжок лише за один слот. + +#### Затримка фіналізації {#finality-delay} + +[Та сама стаття](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf), у якій вперше було описано недорогу атаку з реорганізацією одного блоку, також описувала атаку із затримкою фіналізації (також відому як «збій живучості»), яка покладається на те, що зловмисник є ініціатором блоку для блоку на межі епох. Це критично важливо, оскільки ці блоки на межі епох стають контрольними точками, які Casper FFG використовує для фіналізації частин ланцюжка. Зловмисник просто приховує свій блок доти, доки достатня кількість чесних валідаторів не використає свої голоси FFG на користь блоку на межі попередньої епохи як поточної цілі фіналізації. Потім вони випускають свій прихований блок. Вони атестують свій блок, і решта чесних валідаторів роблять те саме, створюючи форки з різними цільовими контрольними точками. Якщо вони розрахують час правильно, вони завадять фіналізації, оскільки не буде супербільшості 2/3, яка б атестувала будь-який із форків. Чим менша частка, тим точнішим має бути час, оскільки зловмисник безпосередньо контролює менше атестацій, і тим нижчі шанси, що зловмисник контролюватиме валідатор, який пропонує даний блок на межі епох. + +#### Далекосяжні атаки {#long-range-attacks} + +Існує також клас атак, специфічних для блокчейнів із доказом частки, який полягає в тому, що валідатор, який брав участь у генезис-блоці, підтримує окремий форк блокчейну поряд із чесним, зрештою переконуючи набір чесних валідаторів перейти на нього в якийсь слушний час набагато пізніше. Цей тип атаки неможливий в Ethereum через гаджет фіналізації, який гарантує, що всі валідатори погоджуються щодо стану чесного ланцюжка через регулярні проміжки часу («контрольні точки»). Цей простий механізм нейтралізує далекосяжних зловмисників, оскільки клієнти Ethereum просто не будуть реорганізовувати фіналізовані блоки. Нові вузли, що приєднуються до мережі, роблять це, знаходячи довірений хеш нещодавнього стану (контрольна точка «[слабкої суб’єктивності](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)») і використовуючи його як псевдогенезис-блок для подальшої побудови. Це створює «шлюз довіри» для нового вузла, що входить у мережу, перш ніж він зможе почати самостійно перевіряти інформацію. + +#### Відмова в обслуговуванні {#denial-of-service} + +Механізм PoS Ethereum обирає одного валідатора із загального набору валідаторів, щоб він був ініціатором блоку в кожному слоті. Це можна обчислити за допомогою загальновідомої функції, і супротивник може визначити наступного ініціатора блоку трохи раніше, ніж він запропонує свій блок. Потім зловмисник може заспамити ініціатора блоку, щоб перешкодити йому обмінюватися інформацією з іншими учасниками мережі. Для решти мережі це виглядало б так, ніби ініціатор блоку був офлайн, і слот просто залишився б порожнім. Це може бути формою цензури проти певних валідаторів, що заважає їм додавати інформацію в блокчейн. Впровадження виборів єдиного таємного лідера (SSLE) або виборів неєдиного таємного лідера пом'якшить ризики DoS, оскільки тільки ініціатор блоку знає, що його обрали, і вибір неможливо знати заздалегідь. Це ще не реалізовано, але є активною сферою [досліджень і розробок](https://ethresear.ch/t/secret-non-single-leader-election/11789). + +Все це вказує на те, що успішно атакувати Ethereum з невеликою часткою дуже складно. Життєздатні атаки, які були описані тут, вимагають ідеалізованого алгоритму вибору форку, малоймовірних умов мережі, або ж вектори атак вже були закриті відносно незначними виправленнями клієнтського програмного забезпечення. Це, звичайно, не виключає можливості існування вразливостей нульового дня, але демонструє надзвичайно високу планку технічної кваліфікації, знань рівня консенсусу та удачі, необхідних для ефективності зловмисника з меншою часткою. З точки зору зловмисника, найкращим варіантом може бути накопичити якомога більше ефіру та повернутися, озброївшись більшою часткою загальної ставки. + +### Зловмисники, які використовують >= 33% від загальної частки {#attackers-with-33-stake} + +Усі атаки, згадані раніше в цій статті, стають більш імовірними, якщо зловмисник має більше ефіру в стейкінгу для голосування та більше валідаторів, які можуть бути обрані для пропонування блоків у кожному слоті. Тому зловмисний валідатор може прагнути контролювати якомога більше ефіру в стейкінгу. + +33% ефіру в стейкінгу є орієнтиром для зловмисника, оскільки з будь-якою сумою, що перевищує цю, він має можливість запобігти фіналізації ланцюга, не маючи потреби тонко контролювати дії інших валідаторів. Вони можуть просто зникнути всі разом. Якщо 1/3 або більше ефіру в стейкінгу зловмисно атестує або не атестує, то супербільшість у 2/3 не може існувати, і ланцюг не може фіналізуватися. Захистом від цього є витік через неактивність. Витік через неактивність виявляє тих валідаторів, які не атестують або атестують всупереч більшості. Ефір у стейкінгу, що належить цим неатестуючим валідаторам, поступово вичерпується, доки вони в сукупності не будуть становити менше 1/3 від загальної кількості, щоб ланцюг міг знову фіналізуватися. + +Мета витоку через неактивність — знову забезпечити фіналізацію ланцюга. Однак зловмисник також втрачає частину свого ефіру в стейкінгу. Постійна неактивність валідаторів, що представляють 33% загального ефіру в стейкінгу, є дуже дорогою, навіть якщо валідатори не піддаються слешингу. + +Припускаючи, що мережа Ethereum є асинхронною (тобто існують затримки між відправленням та отриманням повідомлень), зловмисник, який контролює 34% загальної частки, може спричинити подвійну фіналізацію. Це тому, що зловмисник може діяти двозначно, коли його обирають продюсером блоку, а потім подвійно голосувати з усіма своїми валідаторами. Це створює ситуацію, коли існує форк блокчейну, кожен з яких має 34% ефіру в стейкінгу, що голосує за нього. Кожен форк вимагає лише 50% голосів решти валідаторів на свою користь, щоб обидва форки були підтримані супербільшістю, у такому випадку обидва ланцюги можуть фіналізуватися (оскільки 34% валідаторів зловмисників + половина решти 66% = 67% на кожному форку). Конкуруючі блоки повинні бути отримані приблизно 50% чесних валідаторів, тому ця атака є життєздатною лише тоді, коли зловмисник має певний ступінь контролю над часом поширення повідомлень по мережі, щоб він міг підштовхнути половину чесних валідаторів до кожного ланцюга. Зловмисник обов'язково знищить всю свою частку (34% від ~10 мільйонів ефіру з сьогоднішнім набором валідаторів), щоб досягти цієї подвійної фіналізації, оскільки 34% його валідаторів будуть одночасно голосувати двічі — це порушення, що карається слешингом з максимальним штрафом за кореляцію. Захистом від цієї атаки є дуже велика вартість знищення 34% загального ефіру в стейкінгу. Відновлення після цієї атаки вимагатиме від спільноти Ethereum координації «поза ланцюгом» та узгодження одного з форків, ігноруючи інший. + +### Зловмисники, які використовують ~50% від загальної частки {#attackers-with-50-stake} + +При 50% ефіру в стейкінгу, зловмисна група валідаторів теоретично може розділити ланцюг на два однаково розмірних форки, а потім просто використати всю свою 50% частку для голосування проти чесного набору валідаторів, тим самим підтримуючи два форки та запобігаючи фіналізації. Витік через неактивність на обох форках врешті-решт призведе до фіналізації обох ланцюгів. На цьому етапі єдиним варіантом є повернення до соціального відновлення. + +Дуже малоймовірно, що ворожа група валідаторів могла б постійно контролювати рівно 50% загальної частки, враховуючи певну мінливість кількості чесних валідаторів, затримки в мережі тощо — величезна вартість здійснення такої атаки в поєднанні з низькою ймовірністю успіху виглядає як сильний стримуючий фактор для раціонального зловмисника, особливо коли невелике додаткове інвестування в отримання _більше ніж_ 50% відкриває набагато більше можливостей. + +При >50% загальної частки зловмисник може домінувати в алгоритмі вибору форку. У цьому випадку зловмисник зможе атестувати з більшістю голосів, що дасть йому достатній контроль для здійснення коротких реорганізацій без необхідності обманювати чесних клієнтів. Чесні валідатори підуть за ним, оскільки їхній алгоритм вибору форку також побачить ланцюг, якому надає перевагу зловмисник, як найважчий, тому ланцюг може фіналізуватися. Це дозволяє зловмиснику цензурувати певні транзакції, робити короткострокові реорганізації та отримувати максимальний MEV, перевпорядковуючи блоки на свою користь. Захистом від цього є величезна вартість мажоритарної частки (наразі трохи менше 19 мільярдів доларів США), якою ризикує зловмисник, оскільки соціальний рівень, швидше за все, втрутиться і прийме чесний міноритарний форк, що різко знецінить частку зловмисника. + +### Зловмисники, що використовують >=66% загальної ставки {#attackers-with-66-stake} + +Зловмисник, що має 66% або більше загального ефіру в стейкінгу, може фіналізувати свій бажаний ланцюг, не змушуючи жодних чесних валідаторів. Зловмисник може просто проголосувати за свій бажаний форк, а потім фіналізувати його, просто тому, що він може голосувати з нечесною супербільшістю. Як мажоритарний стейкхолдер, зловмисник завжди контролюватиме вміст фіналізованих блоків, маючи можливість витрачати, повертати та витрачати знову, цензурувати певні транзакції та реорганізовувати ланцюг за бажанням. Купуючи додатковий ефір для контролю 66% замість 51%, зловмисник фактично купує можливість робити реорганізації ex post та скасування фіналізації (тобто змінювати минуле, а також контролювати майбутнє). Єдиними реальними засобами захисту тут є величезна вартість 66% загального ефіру в стейкінгу та можливість звернутися до соціального рівня для координації прийняття альтернативного форку. Ми можемо розглянути це детальніше в наступному розділі. + +## Люди: остання лінія оборони {#people-the-last-line-of-defense} + +Якщо нечесним валідаторам вдасться фіналізувати свою бажану версію ланцюга, спільнота Ethereum опиниться у скрутному становищі. Канонічний ланцюг містить нечесну частину, вбудовану в його історію, тоді як чесні валідатори можуть бути покарані за атестацію альтернативного (чесного) ланцюга. Зауважте, що фіналізований, але неправильний ланцюг може також виникнути через помилку в клієнті більшості. Зрештою, останнім запасним варіантом є покладатися на соціальний рівень — рівень 0 — для вирішення ситуації. + +Однією з сильних сторін консенсусу PoS Ethereum є наявність [широкого спектру оборонних стратегій](https://youtu.be/1m12zgJ42dI?t=1712), які спільнота може застосувати в разі атаки. Мінімальною відповіддю може бути примусовий вихід валідаторів зловмисників з мережі без будь-якого додаткового штрафу. Щоб знову увійти в мережу, зловмиснику доведеться стати в чергу активації, яка забезпечує поступове зростання набору валідаторів. Наприклад, додавання достатньої кількості валідаторів для подвоєння суми ефіру в стейкінгу займає близько 200 днів, що фактично дає чесним валідаторам 200 днів, перш ніж зловмисник зможе спробувати ще одну атаку 51%. Однак спільнота може також вирішити покарати зловмисника суворіше, відкликавши минулі винагороди або спаливши частину (до 100%) їхнього капіталу в стейкінгу. + +Незалежно від покарання, накладеного на зловмисника, спільнота також повинна разом вирішити, чи є нечесний ланцюг, незважаючи на те, що він є тим, якому надає перевагу алгоритм вибору форку, закодований у клієнтах Ethereum, насправді недійсним і чи повинна спільнота будувати на основі чесного ланцюга. Чесні валідатори могли б колективно погодитися будувати на основі прийнятого спільнотою форку блокчейну Ethereum, який, наприклад, міг би відколотися від канонічного ланцюга до початку атаки або мати примусово видалених валідаторів зловмисників. Чесні валідатори були б зацікавлені в побудові на цьому ланцюзі, оскільки вони уникнули б штрафів, застосованих до них за те, що вони (справедливо) не атестували ланцюг зловмисника. Біржі, платформи для входу в криптовалюту та застосунки, побудовані на Ethereum, імовірно, віддали б перевагу чесному ланцюгу і пішли б за чесними валідаторами на чесний блокчейн. + +Однак це було б значним викликом для управління. Деякі користувачі та валідатори, безсумнівно, постраждають внаслідок повернення до чесного ланцюга, транзакції в блоках, перевірених після атаки, потенційно можуть бути відкочені, що порушить роботу рівня застосунків, і це просто підриває етику деяких користувачів, які схильні вірити, що «код — це закон». Біржі та застосунки, швидше за все, пов'язали дії поза ланцюгом з транзакціями в ланцюзі, які тепер можуть бути відкочені, що спричинить каскад відмов та переглядів, які було б важко справедливо розплутати, особливо якщо незаконно отримані прибутки були змішані, внесені в DeFi або інші деривативи з вторинними наслідками для чесних користувачів. Безсумнівно, деякі користувачі, можливо, навіть інституційні, вже отримали вигоду від нечесного ланцюга, чи то завдяки кмітливості, чи то завдяки щасливому випадку, і можуть виступати проти форку, щоб захистити свої прибутки. Були заклики до репетиції реакції спільноти на атаки >51%, щоб можна було швидко виконати розумне скоординоване пом'якшення наслідків. Є корисне обговорення Віталіка на ethresear.ch [тут](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) і [тут](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), а також у Twitter [тут](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). Метою скоординованої соціальної відповіді має бути дуже цілеспрямоване та конкретне покарання зловмисника та мінімізація наслідків для інших користувачів. + +Управління — це вже складна тема. Управління надзвичайною ситуацією на рівні 0 у відповідь на нечесний фіналізуючий ланцюг, безсумнівно, було б складним для спільноти Ethereum, але це [траплялося](/ethereum-forks/#dao-fork-summary) — [двічі](/ethereum-forks/#tangerine-whistle) — в історії Ethereum). + +Тим не менш, є щось досить задовільне в тому, що останній запасний варіант знаходиться в реальному світі. Зрештою, навіть з цією феноменальною купою технологій над нами, якби найгірше колись сталося, реальним людям довелося б координувати свій вихід з цього. + +## Підсумок {#summary} + +На цій сторінці розглядалися деякі способи, якими зловмисники можуть спробувати використати протокол консенсусу доказу частки Ethereum. Реорганізації та затримки фіналізації були розглянуті для зловмисників зі зростаючою часткою загального ефіру в стейкінгу. Загалом, багатший зловмисник має більше шансів на успіх, оскільки його частка перетворюється на право голосу, яке він може використовувати для впливу на вміст майбутніх блоків. При певних порогових сумах ефіру в стейкінгу сила зловмисника зростає: + +33%: затримка фіналізації + +34%: затримка фіналізації, подвійна фіналізація + +51%: затримка фіналізації, подвійна фіналізація, цензура, контроль над майбутнім блокчейну + +66%: затримка фіналізації, подвійна фіналізація, цензура, контроль над майбутнім і минулим блокчейну + +Існує також низка більш складних атак, які вимагають невеликої кількості ефіру в стейкінгу, але покладаються на дуже досвідченого зловмисника, який має тонкий контроль над часом передачі повідомлень, щоб схилити на свій бік чесний набір валідаторів. + +Загалом, незважаючи на ці потенційні вектори атак, ризик успішної атаки низький, безумовно нижчий, ніж у еквівалентів з доказом роботи. Це пов'язано з величезною вартістю ефіру в стейкінгу, яким ризикує зловмисник, що прагне перевершити чесних валідаторів своєю силою голосу. Вбудований рівень стимулювання «батога і пряника» захищає від більшості зловживань, особливо для зловмисників з низькою часткою. Більш тонкі атаки відскоку та балансування також навряд чи будуть успішними, оскільки реальні умови мережі ускладнюють тонкий контроль над доставкою повідомлень до конкретних підмножин валідаторів, а команди клієнтів швидко закрили відомі вектори атак відскоку, балансування та лавини за допомогою простих виправлень. + +Атаки 34%, 51% або 66%, ймовірно, вимагатимуть позасмугової соціальної координації для вирішення. Хоча це, ймовірно, буде болісно для спільноти, здатність спільноти реагувати позасмугово є сильним стримуючим фактором для зловмисника. Соціальний рівень Ethereum є останнім запобіжником — технічно успішна атака все ще може бути нейтралізована спільнотою, яка погодиться прийняти чесний форк. Буде гонка між зловмисником і спільнотою Ethereum — мільярди доларів, витрачені на 66% атаку, ймовірно, будуть знищені успішною соціальною координаційною атакою, якщо вона буде здійснена досить швидко, залишаючи зловмисника з важкими мішками неліквідного ефіру в стейкінгу на відомому нечесному ланцюгу, ігнорованому спільнотою Ethereum. Імовірність того, що це виявиться прибутковим для зловмисника, настільки низька, що є ефективним стримуючим фактором. Ось чому інвестиції в підтримку згуртованого соціального рівня з тісно узгодженими цінностями є такими важливими. + +## Додаткові матеріали {#further-reading} + +- [Більш детальна версія цієї сторінки](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Віталік про фіналізацію розрахунків](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Документ про LMD GHOST](https://arxiv.org/abs/2003.03052) +- [Документ Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Документ Gasper](https://arxiv.org/pdf/2003.03052.pdf) +- [Специфікації консенсусу щодо посилення ваги ініціатора](https://github.com/ethereum/consensus-specs/pull/2730) +- [Атаки відбиття на ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [Дослідження SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..6cb8273e50b --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: Attestations +description: "Опис атестацій на PoS-системі Ethereum." +lang: uk +--- + +Очікується, що валідатор створюватиме, підписуватиме та транслюватиме атестацію протягом кожної епохи. На цій сторінці описано, як виглядають ці атестації, як вони обробляються та передаються між клієнтами консенсусу. + +## Що таке атестація? {#what-is-an-attestation} + +Кожну [епоху](/glossary/#epoch) (6,4 хвилини) валідатор пропонує мережі атестацію. Атестація валідатора стосується конкретного слота в межах епохи. Мета атестації полягає в тому, щоб проголосувати на користь бачення валідатора щодо блокчейну, зокрема за останній підтверджений блок і перший блок у поточній епосі (відомі як контрольні точки `source` і `target`). Ця інформація об'єднується для всіх учасників-валідаторів, що дозволяє мережі досягти консенсусу щодо стану блокчейну. + +Атестація містить такі компоненти: + +- `aggregation_bits`: бітовий список валідаторів, де позиція відповідає індексу валідатора в його комітеті; значення (0/1) вказує, чи підписав валідатор `data` (тобто чи є він активним і чи згоден з пропонувачем блоку) +- `data`: деталі, що стосуються атестації, як визначено нижче +- `signature`: підпис BLS, що агрегує підписи окремих валідаторів + +Перше завдання для валідатора, що атестує, — створити `data`. `data` містить таку інформацію: + +- `slot`: номер слота, до якого відноситься атестація +- `index`: число, яке ідентифікує, до якого комітету належить валідатор у певному слоті +- `beacon_block_root`: кореневий хеш блоку, який валідатор бачить на чолі ланцюга (результат застосування алгоритму вибору форку) +- `source`: частина голосування за завершення, що вказує на те, що валідатори вважають останнім підтвердженим блоком +- `target`: частина голосування за завершення, що вказує на те, що валідатори вважають першим блоком у поточній епосі + +Після створення `data` валідатор може змінити біт в `aggregation_bits`, що відповідає його власному індексу валідатора, з 0 на 1, щоб показати, що він брав участь. + +Нарешті, валідатор підписує атестацію та транслює її в мережу. + +### Агрегована атестація {#aggregated-attestation} + +Існують значні накладні витрати, пов’язані з передачею цих даних по мережі для кожного валідатора. Тому атестації від окремих валідаторів агрегуються в підмережах, перш ніж транслюватися ширше. Це включає агрегування підписів, щоб атестація, яка транслюється, містила консенсусні `data` та єдиний підпис, сформований шляхом об’єднання підписів усіх валідаторів, які згодні з цими `data`. Це можна перевірити за допомогою `aggregation_bits`, оскільки це надає індекс кожного валідатора в його комітеті (ідентифікатор якого надається в `data`), який можна використовувати для запиту окремих підписів. + +У кожній епосі 16 валідаторів у кожній підмережі обираються `агрегаторами`. Агрегатори збирають усі атестації, про які вони чують через gossip-мережу, які мають `data`, еквівалентні їхнім власним. Відправник кожної відповідної атестації записується в `aggregation_bits`. Потім агрегатори транслюють агрегат атестації в ширшу мережу. + +Коли валідатора обирають пропонувачем блоку, він пакує агреговані атестації з підмереж до останнього слота в новому блоці. + +### Життєвий цикл включення атестації {#attestation-inclusion-lifecycle} + +1. Генерація +2. Поширення +3. Агрегація +4. Поширення +5. Включення + +Життєвий цикл атестації показано на схемі нижче: + +![життєвий цикл атестації](./attestation_schematic.png) + +## Винагороди {#rewards} + +Валідатори отримують винагороду за подання атестацій. Винагорода за атестацію залежить від прапорців участі (source, target і head), базової винагороди та коефіцієнта участі. + +Кожен із прапорців участі може бути істинним або хибним, залежно від поданої атестації та затримки її включення. + +Найкращий сценарій виникає, коли всі три прапорці істинні, і в цьому випадку валідатор заробляє (за кожен правильний прапорець): + +`винагорода += базова винагорода * вага прапорця * коефіцієнт атестації прапорця / 64` + +Коефіцієнт атестації прапорця вимірюється за допомогою суми ефективних балансів усіх атестуючих валідаторів для даного прапорця порівняно із загальним активним ефективним балансом. + +### Базова винагорода {#base-reward} + +Базова винагорода розраховується відповідно до кількості атестуючих валідаторів та їхніх ефективних балансів застейканого ефіру: + +`базова винагорода = ефективний баланс валідатора x 2^6 / SQRT(Ефективний баланс усіх активних валідаторів)` + +#### Затримка включення {#inclusion-delay} + +На момент, коли валідатори голосували за голову ланцюга (`блок n`), `блок n+1` ще не був запропонований. Тому атестації природним чином включаються **на один блок пізніше**, тому всі атестації, які проголосували за те, що `блок n` є головою ланцюга, були включені в `блок n+1`, і **затримка включення** становить 1. Якщо затримка включення подвоюється до двох слотів, винагорода за атестацію зменшується вдвічі, оскільки для розрахунку винагороди за атестацію базова винагорода множиться на величину, обернену до затримки включення. + +### Сценарії атестації {#attestation-scenarios} + +#### Відсутній голосуючий валідатор {#missing-voting-validator} + +Валідатори мають максимум 1 епоху, щоб подати свою атестацію. Якщо атестація була пропущена в епосі 0, вони можуть подати її із затримкою включення в епосі 1. + +#### Відсутній агрегатор {#missing-aggregator} + +Загалом є 16 агрегаторів на епоху. Крім того, випадкові валідатори підписуються на **дві підмережі на 256 епох** і служать резервною копією на випадок відсутності агрегаторів. + +#### Відсутній пропонувач блоку {#missing-block-proposer} + +Зауважте, що в деяких випадках щасливий агрегатор також може стати пропонувачем блоку. Якщо атестація не була включена через те, що пропонувач блоку зник, наступний пропонувач блоку візьме агреговану атестацію та включить її до наступного блоку. Однак **затримка включення** збільшиться на одиницю. + +## Для подальшого читання {#further-reading} + +- [Атестації в анотованій специфікації консенсусу Віталіка](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Атестації в eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..9d03a0285ae --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "Блок-пропозиція" +description: "Пояснення того, як пропонуються блоки в Ethereum з доказом частки." +lang: uk +--- + +Блоки - це основні одиниці блокчейну. Блоки - це дискретні одиниці інформації, які передаються між вузлами, узгоджуються і додаються до бази даних кожного вузла. Ця сторінка пояснює, як вони виробляються. + +## Передумови {#prerequisites} + +Пропозиція блоку є частиною протоколу підтвердження частки. Щоб краще зрозуміти цю сторінку, радимо вам прочитати про [доказ частки](/developers/docs/consensus-mechanisms/pos/) та [архітектуру блоків](/developers/docs/blocks/). + +## Хто створює блоки? {#who-produces-blocks} + +Облікові записи валідаторів пропонують блоки. Облікові записи валідаторів управляються операторами вузлів, які використовують програмне забезпечення валідатора як частину своїх клієнтів виконання і консенсусу і внесли щонайменше 32 ETH в депозитний контракт. Однак кожен валідатор лише іноді відповідає за пропозицію блоку. Ефіріум вимірює час у слотах та епохах. Кожен слот містить 12 секунд, а 32 слоти (6,4 хвилини) складають епоху. Кожен слот - це можливість додати новий блок на Ethereum. + +### Випадковий вибір {#random-selection} + +Один валідатор вибирається псевдовипадковим чином, щоб запропонувати блок у кожному слоті. У блокчейні не існує такого поняття, як справжня випадковість, тому що якби кожен вузол генерував справді випадкові числа, вони не змогли б дійти до консенсусу. Натомість метою є зробити процес вибору валідатора непередбачуваним. Випадковість досягається в Ethereum за допомогою алгоритму під назвою RANDAO, який змішує хеш від пропонента блоку з першоджерелом, яке оновлюється кожного блоку. Це значення використовується для вибору конкретного валідатора із загального набору валідаторів. Вибір валідатора фіксується на дві епохи наперед, щоб захиститися від певних видів маніпуляцій з першоджерелом. + +Хоча валідатори додають до RANDAO в кожному слоті, глобальне значення RANDAO оновлюється лише один раз за епоху. Для обчислення індексу наступної пропозиції блоку значення RANDAO змішується з номером слоту, щоб отримати унікальне значення в кожному слоті. Імовірність того, що буде обрано окремого валідатора, не просто дорівнює `1/N` (де `N` = загальна кількість активних валідаторів). Замість цього він зважується на ефективний баланс ETH кожного валідатора. Максимальний ефективний баланс становить 32 ETH (це означає, що `balance < 32 ETH` призводить до меншої ваги, ніж `balance == 32 ETH`, але `balance > 32 ETH` не призводить до більшої ваги, ніж `balance == 32 ETH`). + +У кожному слоті обирається лише одна пропозиція блоку. За звичайних умов, один виробник блоків створює і випускає один блок у своєму виділеному слоті. Створення двох блоків для одного слоту є порушенням, яке можна вилучити, часто відомим як "двозначність". + +## Як відбувається створення блоку? {#how-is-a-block-created} + +Очікується, що пропонент блоку транслюватиме підписаний блок-маяк, який будується поверх останньої голови ланцюжка відповідно до подання його власного локального алгоритму вибору розгалуження. Алгоритм вибору розгалуження застосовує будь-які атестації в черзі, що залишилися від попереднього слота, а потім знаходить блок із найбільшою накопиченою вагою атестацій у своїй історії. Цей блок є родоначальником нового блоку, створеного автором. + +Пропонент блоку створює блок, збираючи дані з власної локальної бази даних і бачення ланцюжка. Вміст блоку показано у фрагменті нижче: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +Поле `randao_reveal` приймає випадкове значення, що можна перевірити, яке пропонувач блоку створює, підписуючи номер поточної епохи. `eth1_data` — це голос за бачення пропонувачем блоку депозитного контракту, включно з коренем дерева Меркла депозиту та загальною кількістю депозитів, що дає змогу перевіряти нові депозити. `graffiti` — це необов'язкове поле, яке можна використовувати для додавання повідомлення до блоку. `proposer_slashings` і `attester_slashings` — це поля, які містять доказ того, що певні валідатори вчинили правопорушення, що караються слешингом, відповідно до бачення ланцюжка пропонувачем. `deposits` — це список нових депозитів валідаторів, про які відомо пропонувачу блоку, а `voluntary_exits` — це список валідаторів, які бажають вийти, про яких пропонувач блоку дізнався з gossip-мережі на рівні консенсусу. `sync_aggregate` — це вектор, який показує, яких валідаторів раніше було призначено до комітету синхронізації (підмножина валідаторів, які обслуговують дані легких клієнтів) і які брали участь у підписанні даних. + +`execution_payload` дозволяє передавати інформацію про транзакції між клієнтами виконання та консенсусу. `execution_payload` — це блок даних виконання, який вкладається всередину маякового блоку. Поля всередині `execution_payload` відображають структуру блоку, описану в Жовтій книзі Ethereum, за винятком того, що немає оммерів, а `prev_randao` існує замість `difficulty`. Клієнт виконання має доступ до локального пулу транзакцій, про які він дізнався з власної мережі пліток. Ці транзакції виконуються локально, щоб згенерувати оновлену трійку станів, відому як пост-стан. Транзакції включені в `execution_payload` як список під назвою `transactions`, а післястан надається в полі `state-root`. + +Всі ці дані збираються в маячковий блок, підписуються і передаються колегам автора блоку, які поширюють його далі своїм колегам і т. д. + +Дізнайтеся більше про [анатомію блоків](/developers/docs/blocks/). + +## Що відбувається з блоком? {#what-happens-to-blocks} + +Блок додається до локальної бази даних пропонента блоку і транслюється одноранговим користувачам через мережу пліток консенсусного рівня. Коли валідатор отримує блок, він перевіряє дані всередині нього, включаючи перевірку того, що блок має правильного родоначальника, відповідає правильному слоту, що індекс пропонента є очікуваним, що RANDAO-розкриття є дійсним і що пропонент не є зрізаним. `execution_payload` розпаковується, і клієнт-виконавець валідатора повторно виконує транзакції зі списку, щоб перевірити запропоновану зміну стану. Якщо блок проходить всі ці перевірки, кожен валідатор додає його до свого канонічного ланцюжка. Потім процес починається знову в наступному слоті. + +## Винагороди за блок {#block-rewards} + +Автор блоку отримує виплату за свою роботу. Існує `base_reward`, яка розраховується як функція від кількості активних валідаторів та їхніх ефективних балансів. Потім пропонувач блоку отримує частку `base_reward` за кожну дійсну атестацію, включену в блок; що більше валідаторів атестують блок, то більша винагорода пропонувача блоку. Також існує винагорода за повідомлення про валідаторів, які підлягають слешингу, що дорівнює `1/512 * effective balance` за кожного такого валідатора. + +[Докладніше про винагороди та штрафи](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## Для подальшого читання {#further-reading} + +- [Вступ до блоків](/developers/docs/blocks/) +- [Вступ до механізму підтвердження частки володіння (proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) +- [Специфікації консенсусу Ethereum](https://github.com/ethereum/consensus-specs) +- [Вступ до Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Оновлення Ethereum](https://eth2book.info/) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..f3c58a71b08 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "Найбільш поширені питання" +description: "Найбільш поширені питання про proof-of-stake в Ethereum." +lang: uk +--- + +## Що таке підтвердження частки {#what-is-proof-of-stake} + +Підтвердження частки — це клас алгоритмів, що можуть забезпечувати безпеку блокчейнів, гарантуючи, що зловмисники, які діють нечесно, втратять цінні активи. Системи підтвердження частки вимагають, щоб набір валідаторів надав певний актив, який може бути знищений, якщо валідатор продемонструє доказово нечесну поведінку. Ethereum використовує механізм підтвердження частки для захисту блокчейну. + +## Як Proof-of-Stake порівнюється з Proof-of-Work? {#comparison-to-proof-of-work} + +Підтвердження роботи й підтвердження частки — це механізми, які економічно демотивують зловмисників від спаму або шахрайства в мережі. В обох випадках вузли, які активно беруть участь у консенсусі, вкладають певний актив "у мережу", який вони втратять у разі неправомірної поведінки. + +У разі підтвердження роботи цим активом є енергія. Вузол, відомий як майнер, запускає алгоритм, метою якого є обчислення значення швидше, ніж будь-який інший вузол. Найшвидший вузол має право запропонувати блок для ланцюга. Щоб змінити історію ланцюга або домінувати в пропозиції блоків, майнер повинен мати таку обчислювальну потужність, щоб завжди перемагати в змаганні. Це надзвичайно дорого й складно виконати, що захищає ланцюг від атак. Енергія, необхідна для "майнінгу" за допомогою підтвердження роботи, є реальним активом, за який платять майнери. + +Підтвердження частки вимагає, щоб вузли, відомі як валідатори, явно надсилали криптоактив до смарт-контракту. Якщо валідатор поводиться неправомірно, цей криптоактив може бути знищений, оскільки він робить "стейкінг" своїх активів безпосередньо в ланцюг, а не опосередковано через витрати енергії. + +Підтвердження роботи набагато енерговитратніше, оскільки в процесі майнінгу спалюється електроенергія. З іншого боку, підтвердження частки потребує лише дуже невеликої кількості енергії — валідатори Ethereum можуть працювати навіть на пристрої з низьким енергоспоживанням, наприклад, на Raspberry Pi. Вважається, що механізм підтвердження частки Ethereum є безпечнішим, ніж підтвердження роботи, оскільки вартість атаки вища, а наслідки для зловмисника — серйозніші. + +Порівняння Proof-of-Work і Proof-of-Stake є спірним питанням. [Блог Віталіка Бутеріна](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) та дебати між Джастіном Дрейком і Лін Олден дають гарне уявлення про аргументи. + + + +## Чи є підтвердження частки енергоефективним? {#is-pos-energy-efficient} + +Так. Вузли в мережі підтвердження частки використовують незначну кількість енергії. Стороннє дослідження показало, що вся мережа Ethereum із підтвердженням частки споживає близько 0,0026 ТВт·год/рік — приблизно в 13 000 разів менше, ніж геймінг тільки в США. + +[Докладніше про споживання енергії Ethereum](/energy-consumption/). + +## Чи є підтвердження частки безпечним? {#is-pos-secure} + +Підтвердження частки Ethereum є дуже безпечним. Цей механізм ретельно досліджувався, розроблявся та тестувався протягом восьми років, перш ніж був запущений. Гарантії безпеки відрізняються від блокчейнів із підтвердженням роботи. У механізмі підтвердження частки зловмисні валідатори можуть бути активно покарані (зазнати «слешингу») і виключені з набору валідаторів, що коштуватиме їм значної суми ETH. У разі підтвердження роботи зловмисник може продовжувати повторювати свою атаку, доки в нього достатньо хеш-потужності. Також дорожче здійснювати еквівалентні атаки на Ethereum із підтвердженням частки, ніж на Ethereum із підтвердженням роботи. Щоб вплинути на живучість ланцюга, потрібно щонайменше 33 % від загальної кількості ефіру в стейкінгу в мережі (за винятком випадків дуже складних атак із надзвичайно низькою ймовірністю успіху). Щоб контролювати вміст майбутніх блоків, потрібно щонайменше 51 % від загальної кількості ETH у стейкінгу, а для переписування історії — понад 66 % від загальної частки. Протокол Ethereum знищить ці активи в сценаріях атаки 33 % або 51 % і за соціальним консенсусом у сценарії атаки 66 %. + +- [Докладніше про захист Ethereum із підтвердженням частки від зловмисників](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Докладніше про дизайн підтвердження частки](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## Чи робить підтвердження частки Ethereum дешевшим? Чи впливає це оновлення на всі вузли та валідаторів Ethereum? {#does-pos-make-ethereum-cheaper} + +Ні. Вартість транзакції (gas fee) визначається динамічним ринком комісій, який зростає зі збільшенням попиту в мережі. Механізм консенсусу не має прямого впливу на це. + +[Докладніше про газ](/developers/docs/gas). + +## Що таке вузли, клієнти й валідатори? Чи впливає це оновлення на всі вузли та валідаторів Ethereum? {#what-are-nodes-clients-and-validators} + +Вузли — це комп’ютери, підключені до мережі Ethereum. Клієнти — це програмне забезпечення, яке вони запускають і яке перетворює комп’ютер на вузол. Існує два типи клієнтів: клієнти виконання (execution clients) та клієнти консенсусу (consensus clients). Обидва необхідні для створення вузла. Валідатор — це необов’язковий додаток до клієнта консенсусу, який дає змогу вузлу брати участь у консенсусі підтвердження частки. Це означає створення й пропонування блоків, коли їх вибирають, і атестацію блоків, про які вони дізнаються в мережі. Щоб запустити валідатор, оператор вузла повинен внести 32 ETH у депозитний контракт. + +- [Докладніше про вузли та клієнтів](/developers/docs/nodes-and-clients) +- [Докладніше про стейкінг](/staking) + +## Чи є підтвердження частки новою ідеєю? {#is-pos-new} + +Ні. Користувач на BitcoinTalk [запропонував базову ідею підтвердження частки](https://bitcointalk.org/index.php?topic=27787.0) як оновлення для Bitcoin у 2011 році. Минуло одинадцять років, перш ніж його можна було впровадити в головній мережі Ethereum. Деякі інші ланцюги впровадили підтвердження частки раніше за Ethereum, але не специфічний механізм Ethereum (відомий як Gasper). + +## Чим особливе підтвердження частки Ethereum? {#why-is-ethereum-pos-special} + +Механізм підтвердження частки Ethereum є унікальним за своїм дизайном. Це був не перший механізм підтвердження частки, який був розроблений і впроваджений, але він є найнадійнішим. Механізм підтвердження частки відомий як "Casper". Casper визначає, як валідатори обираються для пропонування блоків, як і коли робляться атестації, як атестації підраховуються, винагороди та штрафи для валідаторів, умови слешингу, механізми захисту від збоїв, як-от витік через неактивність, та умови для "завершеності". Завершеність — це умова, за якою для того, щоб блок вважався постійною частиною канонічного ланцюга, за нього повинні проголосувати щонайменше 66 % від загальної кількості ETH у стейкінгу в мережі. Дослідники розробили Casper спеціально для Ethereum, і Ethereum є першим і єдиним блокчейном, який його впровадив. + +Крім Casper, у підтвердженні частки Ethereum використовується алгоритм вибору форка під назвою LMD-GHOST. Це необхідно на випадок виникнення умови, коли для одного слота існують два блоки. Це створює два форки блокчейну. LMD-GHOST обирає той, що має найбільшу "вагу" атестацій. Вага — це кількість атестацій, зважена за ефективним балансом валідаторів. LMD-GHOST є унікальним для Ethereum. + +Комбінація Casper та LMD_GHOST відома як Gasper. + +[Докладніше про Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) + +## Що таке слешинг? {#what-is-slashing} + +Слешинг — це термін, що означає знищення частини частки валідатора та виключення валідатора з мережі. Кількість ETH, втрачених унаслідок слешингу, масштабується залежно від кількості валідаторів, які зазнали слешингу. Це означає, що валідатори, які вступили в змову, караються суворіше, ніж окремі особи. + +[Докладніше про слешинг](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## Чому валідаторам потрібно 32 ETH? {#why-32-eth} + +Валідатори повинні вкладати ETH у стейкінг, щоб їм було що втрачати, якщо вони поводитимуться неправомірно. Причина, чому вони повинні вкладати в стейкінг саме 32 ETH, полягає в тому, щоб вузли могли працювати на скромному обладнанні. Якби мінімальна кількість ETH на валідатора була нижчою, то кількість валідаторів і, отже, кількість повідомлень, які необхідно обробляти в кожному слоті, збільшилася б, а це означає, що для запуску вузла знадобилося б потужніше обладнання. + +## Як обираються валідатори? Чи впливає це оновлення на всі вузли та валідаторів Ethereum? {#how-are-validators-selected} + +Один валідатор псевдовипадково обирається для пропонування блоку в кожному слоті за допомогою алгоритму під назвою RANDAO, який змішує хеш від автора блоку з початковим значенням, що оновлюється з кожним блоком. Це значення використовується для вибору конкретного валідатора із загального набору валідаторів. Вибір валідатора фіксується на дві епохи наперед. + +[Докладніше про вибір валідатора](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## Що таке маніпуляція часткою? {#what-is-stake-grinding} + +Маніпуляція часткою — це категорія атаки на мережі з підтвердженням частки, під час якої зловмисник намагається вплинути на алгоритм вибору валідатора на користь своїх власних валідаторів. Атаки з маніпуляцією часткою на RANDAO вимагають близько половини загальної кількості ETH у стейкінгу. + +[Докладніше про маніпуляцію часткою](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## Що таке соціальний слешинг? {#what-is-social-slashing} + +Соціальний слешинг — це здатність спільноти координувати форк блокчейну у відповідь на атаку. Це дає змогу спільноті відновитися після того, як зловмисник завершив нечесний ланцюг. Соціальний слешинг також може використовуватися проти атак цензури. + +- [Докладніше про соціальний слешинг](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Віталік Бутерін про соціальний слешинг](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## Чи зазнаю я слешингу? {#will-i-get-slashed} + +Як валідатору, дуже важко зазнати слешингу, якщо ви навмисно не вдаєтеся до зловмисної поведінки. Слешинг застосовується тільки в дуже специфічних сценаріях, коли валідатори пропонують кілька блоків для одного слота або суперечать самі собі своїми атестаціями — випадкове виникнення таких ситуацій дуже малоймовірне. + +[Докладніше про умови слешингу](https://eth2book.info/altair/part2/incentives/slashing) + +## У чому полягає проблема «нічого на кону»? {#what-is-nothing-at-stake-problem} + +Проблема «нічого на кону» — це концептуальна проблема деяких механізмів підтвердження частки, де є тільки винагороди й немає штрафів. Якщо нічого не стоїть на кону, прагматичний валідатор однаково радий атестувати будь-які або навіть кілька форків блокчейну, оскільки це збільшує його винагороди. Ethereum обходить цю проблему, використовуючи умови завершеності та слешинг для забезпечення єдиного канонічного ланцюга. + +[Докладніше про проблему «нічого на кону»](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## Що таке алгоритм вибору форка? {#what-is-a-fork-choice-algorithm} + +Алгоритм вибору форка реалізує правила, що визначають, який ланцюг є канонічним. За оптимальних умов немає потреби в правилі вибору форка, оскільки на кожен слот припадає лише один автор блоку й один блок для вибору. Однак іноді кілька блоків для одного й того ж слота або інформація, що надходить із запізненням, призводять до появи кількох варіантів організації блоків біля початку ланцюга. У цих випадках усі клієнти повинні однаково реалізовувати певні правила, щоб переконатися, що всі вони обирають правильну послідовність блоків. Алгоритм вибору форка кодує ці правила. + +Алгоритм вибору форка Ethereum називається LMD-GHOST. Він обирає форк із найбільшою вагою атестацій, тобто той, за який проголосувала більшість ETH у стейкінгу. + +[Докладніше про LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Що таке завершеність у підтвердженні частки? {#what-is-finality} + +Завершеність у підтвердженні частки — це гарантія того, що певний блок є постійною частиною канонічного ланцюга й не може бути скасований, якщо не станеться збій консенсусу, під час якого зловмисник спалює 33 % від загальної кількості ефіру в стейкінгу. Це "криптоекономічна" завершеність, на відміну від "імовірнісної завершеності", яка характерна для блокчейнів із підтвердженням роботи. При імовірнісній завершеності немає явних завершених/незавершених станів для блоків — просто стає все менш імовірним, що блок може бути видалений з ланцюга в міру його старіння, і користувачі самі визначають, коли вони достатньо впевнені, що блок "безпечний". При криптоекономічній завершеності за пари контрольних блоків повинні проголосувати 66 % ефіру в стейкінгу. Якщо ця умова виконується, блоки між цими контрольними точками явно вважаються "завершеними". + +[Докладніше про завершеність](/developers/docs/consensus-mechanisms/pos/#finality) + +## Що таке "слабка суб’єктивність"? {#what-is-weak-subjectivity} + +Слабка суб’єктивність — це особливість мереж із підтвердженням частки, де соціальна інформація використовується для підтвердження поточного стану блокчейну. Нові вузли або вузли, які знову приєднуються до мережі після тривалого перебування в автономному режимі, можуть отримати останній стан, щоб вузол міг негайно перевірити, чи перебуває він у правильному ланцюзі. Ці стани відомі як "контрольні точки слабкої суб’єктивності", і їх можна отримати від інших операторів вузлів поза мережею, з оглядачів блоків або з кількох загальнодоступних кінцевих точок. + +[Докладніше про слабку суб’єктивність](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## Чи є підтвердження частки стійким до цензури? {#is-pos-censorship-resistant} + +Стійкість до цензури наразі важко довести. Однак, на відміну від підтвердження роботи, підтвердження частки пропонує можливість координувати слешинги для покарання валідаторів, які вдаються до цензури. У протоколі очікуються зміни, які відокремлять конструкторів блоків від авторів блоків і запровадять списки транзакцій, які конструктори повинні включати в кожен блок. Ця пропозиція відома як розділення пропонента-конструктора й допомагає запобігти цензуруванню транзакцій валідаторами. + +[Докладніше про розділення пропонента-конструктора](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Чи може система підтвердження частки Ethereum зазнати атаки 51 %? {#pos-51-attack} + +Так. Підтвердження частки є вразливим до атак 51 %, як і підтвердження роботи. Замість того, щоб зловмиснику було потрібно 51 % хеш-потужності мережі, зловмиснику потрібен 51 % від загальної кількості ETH у стейкінгу. Зловмисник, який накопичує 51 % від загальної частки, отримує контроль над алгоритмом вибору форка. Це дає змогу зловмиснику цензурувати певні транзакції, здійснювати короткострокові реорганізації та видобувати MEV, змінюючи порядок блоків на свою користь. + +[Докладніше про атаки на підтвердження частки](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## Що таке соціальна координація й чому вона потрібна? {#what-is-social-coordination} + +Соціальна координація — це остання лінія захисту для Ethereum, яка дала б змогу відновити чесний ланцюг після атаки, що завершила нечесні блоки. У цьому випадку спільнота Ethereum повинна буде координуватися "поза мережею" й домовитися про використання чесного форку меншості, застосовуючи слешинг до валідаторів зловмисника в процесі. Це також вимагатиме, щоб застосунки та біржі визнали чесний форк. + +[Докладніше про соціальну координацію](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## Чи стають багаті багатшими в системі підтвердження частки? {#do-rich-get-richer} + +Що більше в когось ETH для стейкінгу, то більше валідаторів він може запустити й то більше винагород може отримати. Винагороди масштабуються лінійно залежно від суми ETH у стейкінгу, і кожен отримує однаковий відсотковий дохід. Підтвердження роботи збагачує багатих більше, ніж підтвердження частки, оскільки багатші майнери, які купують обладнання в великих масштабах, отримують вигоду від ефекту масштабу, що означає, що зв’язок між багатством і винагородою є нелінійним. + +## Чи є підтвердження частки більш централізованим, ніж підтвердження роботи? {#is-pos-decentralized} + +Ні, підтвердження роботи схильне до централізації, оскільки витрати на майнінг зростають і витісняють з ринку приватних осіб, потім невеликі компанії тощо. Поточна проблема з підтвердженням частки — це вплив похідних інструментів ліквідного стейкінгу (LSD). Це токени, що представляють ETH у стейкінгу в якогось провайдера, які будь-хто може обміняти на вторинних ринках без фактичного виведення ETH зі стейкінгу. LSD дають змогу користувачам робити стейкінг менш ніж 32 ETH, але вони також створюють ризик централізації, коли кілька великих організацій можуть у підсумку контролювати значну частину частки. Ось чому [соло-стейкінг](/staking/solo) є найкращим варіантом для Ethereum. + +[Докладніше про централізацію частки в LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Чому я можу робити стейкінг тільки ETH? Як можна конвертувати Eth після хардфорку? {#why-can-i-only-stake-eth} + +ETH — це внутрішня валюта Ethereum. Важливо мати єдину валюту, у якій номіновані всі частки, як для обліку ефективних балансів для зважування голосів, так і для безпеки. ETH сам по собі є фундаментальним компонентом Ethereum, а не смарт-контрактом. Включення інших валют значно збільшило б складність і знизило б безпеку стейкінгу. + +## Чи є Ethereum єдиним блокчейном із підтвердженням частки? {#is-ethereum-the-only-pos-blockchain} + +Ні, існує кілька блокчейнів із підтвердженням частки. Жоден не є ідентичним Ethereum; механізм підтвердження частки Ethereum є унікальним. + +## Що таке The Merge? {#what-is-the-merge} + +The Merge — це момент, коли Ethereum вимкнув свій механізм консенсусу на основі підтвердження роботи та ввімкнув механізм консенсусу на основі підтвердження частки. The Merge відбулося 15 вересня 2022 року. + +[Докладніше про The Merge](/roadmap/merge) + +## Що таке живучість і безпека? {#what-are-liveness-and-safety} + +Живучість і безпека — це дві фундаментальні проблеми безпеки блокчейну. Живучість — це доступність ланцюга, що завершується. Якщо ланцюг перестає завершуватися або користувачі не можуть легко отримати до нього доступ, це збої живучості. Надзвичайно висока вартість доступу також може вважатися збоєм живучості. Безпека означає, наскільки важко атакувати ланцюг, тобто завершити суперечливі контрольні точки. + +[Докладніше в документі Casper](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..78b77c9a0e3 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Пояснення механізму підтвердження частки Gasper." +lang: uk +--- + +Gasper — це комбінація Casper the Friendly Finality Gadget (Casper-FFG) і алгоритму вибору розгалуження LMD-GHOST. Разом ці компоненти утворюють консенсусний механізм, що забезпечує доказ ставки Ethereum. Casper — це механізм, який оновлює певні блоки до «завершених», щоб нові учасники мережі могли бути впевнені, що вони синхронізують канонічний ланцюжок. Алгоритм вибору форка використовує накопичені голоси, щоб вузли могли легко вибрати правильний, коли в блокчейні виникають форки. + +**Зверніть увагу,** що оригінальне визначення Casper-FFG було дещо оновлено для включення в Gasper. На цій сторінці розглядаємо оновлену версію. + +## Передумови + +Щоб зрозуміти цей матеріал, необхідно прочитати вступну сторінку про [доказ частки володіння](/developers/docs/consensus-mechanisms/pos/). + +## Роль Gasper {#role-of-gasper} + +Гаспер сидить на вершині блокчейну з підтвердженням частки, де вузли надають ефір як гарантійний депозит, який можна знищити, якщо вони ліниві або нечесні, пропонуючи або перевіряючи блоки. Gasper — це механізм, який визначає, як валідатори отримують винагороду та покарання, вирішують, які блоки приймати та відхиляти, а також який форк блокчейну будувати. + +## Що таке остаточність? {#what-is-finality} + +Завершеність — це властивість певних блоків, яка означає, що їх неможливо повернути, якщо не відбувся критичний збій консенсусу, і зловмисник знищив принаймні 1/3 загального ефіру. Завершені блоки можна розглядати як інформацію, щодо якої блокчейн впевнений. Блок має пройти двоетапну процедуру оновлення, щоб завершити блок: + +1. Дві третини від загального поставленого ефіру повинні були проголосувати за включення цього блоку в канонічний ланцюг. Ця умова покращує блок до «вирівняного». Виправдані блоки навряд чи будуть скасовані, але за певних умов це можливо. +2. Коли інший блок вирівнюється поверх вирівняного блоку, він оновлюється до «завершеного». Завершення блоку — це зобов’язання включити блок у канонічний ланцюг. Його неможливо скасувати, якщо зловмисник не знищить мільйони ефірів (мільярди доларів США). + +Ці оновлення блоків відбуваються не в кожному слоті. Натомість можна обґрунтувати та завершити лише межі епох. Ці блоки відомі як 'контрольно-пропускні пункти'. Оновлення враховує пари контрольних точок. Між двома послідовними контрольними точками має існувати «зв’язок надбільшості» (тобто дві третини від загального обсягу застейканого ефіру, що голосують за те, що контрольна точка B є правильним нащадком контрольної точки A), щоб оновити менш актуальну контрольну точку до статусу «фіналізована», а більш новий блок — до статусу «обґрунтований». + +Оскільки остаточність вимагає згоди на дві третини, що блок є канонічним, зловмисник не може створити альтернативний завершений ланцюжок без: + +1. Володіння або маніпулювання двома третинами загального ефіру. +2. Знищення щонайменше однієї третини загального ефіру, що ставиться на ставку. + +Перша умова виникає через те, що для завершення ланцюжка потрібні дві третини ефіру, який ставиться на ставку. Друга умова виникає тому, що якщо дві третини загальної частки проголосували за обидва вилки, то одна третина має проголосувати за обидва. Подвійне голосування є різкою умовою, яка буде максимально покарана, і одна третина загальної частки буде знищена. Станом на травень 2022 року для цього зловмисник повинен спалити ефір на суму близько 10 мільярдів доларів. Алгоритм, який обґрунтовує та фіналізує блоки в Gasper, є дещо зміненою формою [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). + +### Стимули та слешинг {#incentives-and-slashing} + +Валідатори отримують винагороду за чесну пропозицію та перевірку блоків. Ефір отримує винагороду та додається до їхньої ставки. З іншого боку, валідатори, які відсутні та не діють, коли їх викликають, втрачають ці винагороди, а іноді втрачають невелику частину своєї існуючої частки. Однак штрафи за перебування в автономному режимі невеликі і в більшості випадків дорівнюють альтернативним витратам через відсутність винагород. Однак деякі дії валідатора дуже важко виконати випадково, і вони вказують на зловмисний намір, як-от пропонування кількох блоків для одного слота, підтвердження кількох блоків для одного слота або суперечність попереднім голосуванням контрольних точок. Це «різна» поведінка, яка карається суворіше — скорочення призводить до знищення певної частки валідатора та видалення валідатора з мережі валідаторів. Цей процес займає 36 днів. У день 1, початковий штраф становить до 1 ETH. Потім ефір скороченого валідатора повільно стікає протягом періоду виходу, але на 18 день вони отримують «кореляційний штраф», який стає більшим, коли більше валідаторів скорочуються приблизно в той самий час. Максимальний штраф — уся частка. Ці винагороди та покарання створені, щоб стимулювати чесних валідаторів і перешкоджати атакам у мережі. + +### Витік через неактивність {#inactivity-leak} + +Крім безпеки, Gasper також забезпечує «правдоподібну жвавість». Це умова, що якщо дві третини від загального ефіру чесно голосують і дотримуються протоколу, ланцюжок зможе завершитися незалежно від будь-якої іншої активності (такої як атаки, проблеми з затримкою або скорочення). Іншими словами, одна третина загального ефіру має бути якимось чином скомпрометована, щоб запобігти завершенню ланцюжка. У Gasper існує додаткова лінія захисту від збою в живучості, відома як «витік неактивності». Цей механізм активується, якщо ланцюжок не вдалося завершити протягом більше чотирьох епох. У валідаторів, які активно не підтверджують мажоритарний ланцюжок, їхня частка поступово втрачається, доки більшість не отримає дві третини загальної частки, гарантуючи, що збої в живучості є лише тимчасовими. + +### Вибір форку {#fork-choice} + +Оригінальне визначення Casper-FFG включало алгоритм вибору форка, який встановлював правило: `дотримуватися ланцюга, що містить обґрунтовану контрольну точку з найбільшою висотою`, де висота визначається як найбільша відстань від генезис-блока. У Gasper вихідне правило вибору форка застаріло на користь більш складного алгоритму під назвою LMD-GHOST. Важливо розуміти, що за звичайних умов правило вибору форка непотрібне – для кожного слота існує один пропонатор блоку, і чесні валідатори підтверджують це. Лише у випадках великої асинхронності мережі або коли нечесний пропонент блоку помилився, необхідний алгоритм вибору розгалуження. Однак, коли такі випадки все ж виникають, алгоритм вибору форка є критичним захистом, який забезпечує правильний ланцюжок. + +LMD-GHOST розшифровується як «останнє кероване повідомленням жадібне найважче спостережене піддерево». Це важкий на жаргоні спосіб визначення алгоритму, який вибирає розгалуження з найбільшою накопиченою вагою атестацій як канонічне (жадібне найважче піддерево), і якщо кілька повідомлень отримано від валідатора, розглядається лише останнє (останнє -повідомлення). Перш ніж додати найважчий блок до свого канонічного ланцюга, кожен валідатор оцінює кожен блок за цим правилом. + +## Додаткові матеріали {#further-reading} + +- [Gasper: поєднання GHOST і Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..f6176e9b0d3 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: Proof-of-stake (PoS) +description: "Пояснення протоколу консенсусу proof-of-work та його ролі в Ethereum." +lang: uk +--- + +Доказ частки (PoS) лежить в основі [механізму консенсусу](/developers/docs/consensus-mechanisms/) Ethereum. Ethereum перейшов на механізм доказу частки у 2022 році, оскільки він є більш безпечним, менш енергоємним і кращим для впровадження нових рішень для масштабування порівняно з попередньою архітектурою [доказу виконаної роботи](/developers/docs/consensus-mechanisms/pow). + +## Передумови {#prerequisites} + +Для кращого розуміння цієї сторінки ми рекомендуємо вам спочатку ознайомитися з [механізмами консенсусу](/developers/docs/consensus-mechanisms/). + +## Що являє собою підтвердження ставки (PoS)? {#what-is-pos} + +Доказ частки — це спосіб довести, що валідатори вклали в мережу щось цінне, що може бути знищене, якщо вони діятимуть нечесно. У системі доказу частки Ethereum валідатори явно вкладають капітал у формі ETH у смарт-контракт на Ethereum. Потім валідатор відповідає за перевірку того, що нові блоки, які поширюються мережею, є дійсними, а також за періодичне створення та поширення нових блоків. Якщо вони намагатимуться обдурити мережу (наприклад, пропонуючи кілька блоків, коли вони повинні надіслати один, або надсилаючи суперечливі атестації), частина або вся їхня частка в ETH може бути знищена. + +## Валідатори {#validators} + +Щоб стати валідатором, користувач повинен внести 32 ETH на депозитний контракт і запустити три окремі програми: клієнт виконання, клієнт консенсусу та клієнт валідатора. Після внесення ETH користувач потрапляє в чергу активації, яка обмежує швидкість приєднання нових валідаторів до мережі. Після активації валідатори отримують нові блоки від пірів у мережі Ethereum. Транзакції, доставлені в блоці, виконуються повторно, щоб перевірити, чи є запропоновані зміни в стані Ethereum дійсними, і перевіряється підпис блоку. Потім валідатор надсилає голос (який називається атестацією) на користь цього блоку по всій мережі. + +Тоді як у системі доказу виконаної роботи час створення блоків визначається складністю майнінгу, у системі доказу частки темп є фіксованим. Час у системі доказу частки Ethereum ділиться на слоти (12 секунд) та епохи (32 слоти). У кожному слоті випадковим чином обирається один валідатор, який стає пропонувачем блоку. Цей валідатор відповідає за створення нового блоку та його розсилку іншим вузлам у мережі. Також у кожному слоті випадковим чином обирається комітет валідаторів, голоси яких використовуються для визначення дійсності запропонованого блоку. Розподіл набору валідаторів на комітети важливий для підтримки керованого навантаження на мережу. Комітети розподіляють набір валідаторів таким чином, щоб кожен активний валідатор атестував у кожній епосі, але не в кожному слоті. + +## Як виконується транзакція в Ethereum PoS {#transaction-execution-ethereum-pos} + +Нижче наведено повне пояснення того, як транзакція виконується в системі доказу частки Ethereum. + +1. Користувач створює та підписує [транзакцію](/developers/docs/transactions/) своїм приватним ключем. Зазвичай це робиться через гаманець або бібліотеку, таку як [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) тощо, але насправді користувач робить запит до вузла за допомогою [JSON-RPC API](/developers/docs/apis/json-rpc/) Ethereum. Користувач визначає кількість газу, яку він готовий заплатити як чайові валідатору, щоб заохотити його включити транзакцію в блок. [Чайові](/developers/docs/gas/#priority-fee) виплачуються валідатору, тоді як [базова комісія](/developers/docs/gas/#base-fee) спалюється. +2. Транзакція подається до [клієнта виконання](/developers/docs/nodes-and-clients/#execution-client) Ethereum, який перевіряє її дійсність. Це означає перевірку того, чи має відправник достатньо ETH для виконання транзакції та чи підписав він її правильним ключем. +3. Якщо транзакція дійсна, клієнт виконання додає її до свого локального мемпулу (списку очікуваних транзакцій), а також транслює її іншим вузлам через мережу пліток рівня виконання. Коли інші вузли дізнаються про транзакцію, вони також додають її до свого локального мемпулу. Досвідчені користувачі можуть утриматися від трансляції своєї транзакції та натомість переслати її спеціалізованим конструкторам блоків, таким як [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Це дає їм змогу організовувати транзакції в майбутніх блоках для отримання максимального прибутку ([MEV](/developers/docs/mev/#mev-extraction)). +4. Один із вузлів-валідаторів у мережі є пропонувачем блоку для поточного слоту, попередньо обраний псевдовипадковим чином за допомогою RANDAO. Цей вузол відповідає за створення та трансляцію наступного блоку, який буде додано до блокчейну Ethereum, та оновлення глобального стану. Вузол складається з трьох частин: клієнта виконання, клієнта консенсусу та клієнта валідатора. Клієнт виконання об’єднує транзакції з локального мемпулу в "корисне навантаження виконання" та виконує їх локально, щоб згенерувати зміну стану. Ця інформація передається до клієнта консенсусу, де корисне навантаження виконання загортається як частина "блоку-маяка", який також містить інформацію про винагороди, штрафи, слешинг, атестації тощо, що дає змогу мережі домовитися про послідовність блоків на чолі ланцюга. Зв’язок між клієнтами виконання та консенсусу детальніше описаний у розділі [Підключення клієнтів консенсусу та виконання](/developers/docs/networking-layer/#connecting-clients). +5. Інші вузли отримують новий блок-маяк у мережі пліток рівня консенсусу. Вони передають його своєму клієнту виконання, де транзакції виконуються повторно локально, щоб переконатися, що запропонована зміна стану є дійсною. Потім клієнт валідатора атестує, що блок є дійсним і є логічним наступним блоком у його баченні ланцюга (тобто він будується на ланцюзі з найбільшою вагою атестацій, як визначено в [правилах вибору форку](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Блок додається до локальної бази даних у кожному вузлі, який його атестує. +6. Транзакція може вважатися "фіналізованою", якщо вона стала частиною ланцюга зі "зв’язком супербільшості" між двома контрольними точками. Контрольні точки створюються на початку кожної епохи, і вони існують для того, щоб врахувати той факт, що лише частина активних валідаторів атестує в кожному слоті, але всі активні валідатори атестують протягом кожної епохи. Тому «зв’язок супербільшості» може бути продемонстрований лише між епохами (це коли 66% від загальної суми вкладених ETH у мережі погоджуються щодо двох контрольних точок). + +Більше деталей про завершення можна знайти нижче. + +## Завершеність {#finality} + +Транзакція має "завершення" в розподілених мережах, коли вона є частиною блоку, який неможливо змінити без спалювання великої кількості ETH. В Ethereum на доказі частки це керується за допомогою блоків "контрольних точок". Перший блок у кожній епосі є контрольною точкою. Валідатори голосують за пари контрольних точок, які вони вважають дійсними. Якщо пара контрольних точок набирає голоси, що представляють щонайменше дві третини від загальної суми вкладених ETH, контрольні точки оновлюються. Новіша з двох (цільова) стає "обґрунтованою". Рання з двох уже обґрунтована, оскільки вона була "цільовою" в попередній епосі. Тепер вона оновлюється до статусу "фіналізованої". Цей процес оновлення контрольних точок обробляється **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG — це інструмент завершення блоку для консенсусу. Після того як блок фіналізовано, його не можна скасувати або змінити без слешингу більшості стейкерів, що робить це економічно невигідним. + +Щоб скасувати фіналізований блок, зловмисник повинен буде втратити щонайменше третину від загальної суми вкладених ETH. Точна причина цього пояснюється в цьому [дописі в блозі Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Оскільки завершення вимагає більшості у дві третини, зловмисник може перешкодити мережі досягти завершення, голосуючи однією третиною від загальної частки. Існує механізм захисту від цього: [витік через неактивність](https://eth2book.info/bellatrix/part2/incentives/inactivity). Він активується щоразу, коли ланцюжок не вдається фіналізувати протягом понад чотирьох епох. Витік через неактивність поступово зменшує частку ETH у валідаторів, які голосують проти більшості, дозволяючи більшості відновити дві третини голосів і фіналізувати ланцюжок. + +## Крипто-економічна безпека {#crypto-economic-security} + +Запуск валідатора — це зобов’язання. Очікується, що валідатор підтримуватиме достатнє апаратне забезпечення та підключення до мережі для участі у валідації та пропонуванні блоків. Натомість валідатор отримує винагороду в ETH (його баланс частки збільшується). З іншого боку, участь як валідатор також відкриває нові можливості для користувачів атакувати мережу для особистої вигоди чи саботажу. Щоб запобігти цьому, валідатори втрачають винагороди в ETH, якщо вони не беруть участі в роботі, коли це потрібно, а їхня існуюча частка може бути знищена, якщо вони діють нечесно. Дві основні поведінки можуть вважатися нечесними: пропонування кількох блоків в одному слоті (двозначність) і подання суперечливих атестацій. + +Розмір слешингу ETH залежить від того, скільки валідаторів також підлягають слешингу приблизно в той самий час. Це відомо як ["кореляційний штраф"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), і він може бути незначним (~1% частки для одного валідатора, підданого слешингу) або може призвести до знищення 100% частки валідатора (подія масового слешингу). Він накладається на півдорозі періоду примусового виходу, який починається з негайного штрафу (до 1 ETH) у день 1, кореляційного штрафу в день 18 і, нарешті, виключення з мережі в день 36. Вони щодня отримують незначні штрафи за атестацію, оскільки присутні в мережі, але не подають голоси. Все це означає, що скоординована атака буде дуже дорогою для зловмисника. + +## Вибір форку {#fork-choice} + +Коли мережа працює оптимально та чесно, на чолі ланцюга завжди є лише один новий блок, і всі валідатори його атестують. Однак валідатори можуть мати різні уявлення про початок ланцюга через затримку в мережі або тому, що пропонувач блоку створив неоднозначність. Тому клієнтам консенсусу потрібен алгоритм, щоб вирішити, якому з них віддати перевагу. Алгоритм, що використовується в Ethereum на доказі частки, називається [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), і він працює, визначаючи форк, який має найбільшу вагу атестацій у своїй історії. + +## Доказ частки та безпека {#pos-and-security} + +Загроза [атаки 51%](https://www.investopedia.com/terms/1/51-attack.asp) все ще існує в системі доказу частки, як і в системі доказу виконаної роботи, але для зловмисників вона ще ризикованіша. Зловмиснику знадобиться 51% вкладених ETH. Потім вони могли б використовувати власні атестації, щоб переконатися, що їхній бажаний форк був тим, що мав найбільше накопичених атестацій. «Вага» накопичених атестацій — це те, що клієнти консенсусу використовують для визначення правильного ланцюга, тому цей зловмисник зможе зробити свій форк канонічним. Однак перевагою доказу частки над доказом виконаної роботи є те, що спільнота має гнучкість у організації контратаки. Наприклад, чесні валідатори могли б вирішити продовжувати будувати на міноритарному ланцюзі та ігнорувати форк зловмисника, заохочуючи додатки, біржі та пули робити те ж саме. Вони також могли б вирішити примусово видалити зловмисника з мережі та знищити його вкладені ETH. Це сильні економічні засоби захисту від атаки 51%. + +Крім атак 51%, зловмисники можуть також спробувати інші види зловмисних дій, такі як: + +- атаки з великої відстані (хоча гаджет завершення нейтралізує цей вектор атаки) +- короткострокові «реорги» (хоча підвищення пропонувача та кінцеві терміни атестації пом’якшують це) +- атаки відскоку та балансування (також пом'якшуються підвищенням пропонувача, і ці атаки в будь-якому випадку були продемонстровані лише в ідеалізованих умовах мережі) +- лавинні атаки (нейтралізуються правилом алгоритмів вибору форку, яке враховує лише останнє повідомлення) + +Загалом, доказ частки, як він реалізований на Ethereum, продемонстрував, що є більш економічно безпечним, ніж доказ виконаної роботи. + +## Переваги та недоліки {#pros-and-cons} + +| Переваги | Недоліки | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | +| Стейкінг полегшує участь окремих осіб у захисті мережі, сприяючи децентралізації. вузол валідатора можна запустити на звичайному ноутбуці. Пули для стейкінгу дозволяють користувачам стейкати, не маючи 32 ETH. | Доказ частки є новішим і менш перевіреним у боях порівняно з доказом виконаної роботи | +| Стейкінг більше децентралізований. Ефект масштабу не застосовується так само, як для майнінгу PoW. | Доказ частки складніший у реалізації, ніж доказ виконаної роботи | +| Доказ частки пропонує більшу крипто-економічну безпеку, ніж доказ виконаної роботи | Користувачам потрібно запустити три програми для участі в системі доказу частки Ethereum. | +| Для стимулювання учасників мережі потрібна менша емісія нових ETH | | + +### Порівняння з доказом виконаної роботи {#comparison-to-proof-of-work} + +Спочатку Ethereum використовував доказ виконаної роботи, але у вересні 2022 року перейшов на доказ частки. PoS пропонує кілька переваг над PoW, наприклад: + +- краща енергоефективність – не потрібно витрачати багато енергії на обчислення доказу виконаної роботи +- нижчі бар'єри для входу, зменшені вимоги до обладнання – не потрібно елітного обладнання, щоб мати шанс створювати нові блоки +- зменшений ризик централізації – доказ частки має призвести до більшої кількості вузлів, що захищають мережу +- через низькі енергетичні вимоги для стимулювання участі потрібна менша емісія ETH +- економічні штрафи за неправомірну поведінку роблять атаки типу 51% дорожчими для зловмисника порівняно з доказом виконаної роботи +- спільнота може вдатися до соціального відновлення чесного ланцюга, якщо атака 51% подолає крипто-економічний захист. + +## Для подальшого читання {#further-reading} + +- [Поширені питання про доказ частки](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Віталік Бутерін_ +- [Що таке доказ частки](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Що таке доказ частки і чому це важливо](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Віталік Бутерін_ +- [Чому доказ частки (листопад 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Віталік Бутерін_ +- [Доказ частки: як я навчився любити слабку суб'єктивність](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Віталік Бутерін_ +- [Атаки та захист Ethereum на доказі частки](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Філософія дизайну доказу частки](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Віталік Бутерін_ +- [Відео: Віталік Бутерін пояснює доказ частки Лексу Фрідману](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## Пов'язані теми {#related-topics} + +- [Підтвердження роботи](/developers/docs/consensus-mechanisms/pow/) +- [Доказ повноважень](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..c049e55d7f1 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "Ключі в Ethereum на основі доказу частки" +description: "Пояснення ключів, що використовуються в механізмі консенсусу Ethereum на основі доказу частки" +lang: uk +--- + +Ethereum захищає активи користувачів за допомогою криптографії з відкритим і закритим ключами. Відкритий ключ використовується як основа для адреси Ethereum, тобто він видимий для широкого загалу й використовується як унікальний ідентифікатор. Приватний (або «секретний») ключ має бути доступний лише власнику облікового запису. Приватний ключ використовується для «підпису» транзакцій і даних, щоб криптографія могла довести, що власник схвалює певну дію конкретного приватного ключа. + +Ключі Ethereum генеруються за допомогою [криптографії на еліптичних кривих](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). + +Однак, коли Ethereum перейшов з [доказу роботи](/developers/docs/consensus-mechanisms/pow) на [доказ частки](/developers/docs/consensus-mechanisms/pos), до Ethereum було додано новий тип ключа. Початкові ключі працюють так само, як і раніше — не було жодних змін у ключах на основі еліптичних кривих, що захищають облікові записи. Проте користувачам знадобився новий тип ключа для участі в механізмі доказу частки шляхом стейкінгу ETH та запуску валідаторів. Ця потреба виникла через проблеми з масштабованістю, пов’язані з великою кількістю повідомлень, що передаються між великою кількістю валідаторів, що вимагало криптографічного методу, який можна було б легко агрегувати для зменшення обсягу комунікації, необхідної для досягнення консенсусу в мережі. + +Цей новий тип ключа використовує [схему підпису **Боне-Лінна-Шахама (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS дозволяє дуже ефективно агрегувати підписи, а також здійснювати зворотну розробку агрегованих індивідуальних ключів валідатора, і ідеально підходить для керування діями між валідаторами. + +## Два типи ключів валідатора {#two-types-of-keys} + +До переходу на доказ частки користувачі Ethereum мали лише один приватний ключ на основі еліптичних кривих для доступу до своїх коштів. Із запровадженням доказу частки користувачам, які хотіли стати соло-стейкерами, також знадобилися **ключ валідатора** та **ключ для виведення коштів**. + +### Ключ валідатора {#validator-key} + +Ключ підпису валідатора складається з двох елементів: + +- **Приватний** ключ валідатора +- **Відкритий** ключ валідатора + +Призначення приватного ключа валідатора полягає в підписанні ончейн-операцій, таких як пропозиції блоків та атестації. Через це ці ключі повинні зберігатися в гарячому гаманці. + +Ця гнучкість має перевагу в тому, що ключі підпису валідатора можна дуже швидко переміщати з одного пристрою на інший, однак, якщо їх буде втрачено або вкрадено, зловмисник може **діяти зловмисно** кількома способами: + +- Спричинити слешинг валідатора шляхом: + - Бути пропонентом і підписати два різні маякові блоки для одного слоту + - Бути атестатором і підписати атестацію, яка «оточує» іншу + - Бути атестатором і підписати дві різні атестації, що мають однакову ціль +- Примусово ініціювати добровільний вихід, що зупиняє стейкінг валідатора та надає доступ до його балансу ETH власнику ключа для виведення коштів + +**Відкритий ключ валідатора** включається в дані транзакції, коли користувач вносить ETH на депозитний контракт для стейкінгу. Це відомо як _дані депозиту_, і це дозволяє Ethereum ідентифікувати валідатора. + +### Облікові дані для виведення {#withdrawal-credentials} + +Кожен валідатор має властивість, відому як _облікові дані для виведення_. Перший байт цього 32-байтного поля ідентифікує тип облікового запису: `0x00` представляє оригінальні облікові дані BLS (до оновлення Shapella, без можливості виведення), `0x01` представляє застарілі облікові дані, які вказують на адресу виконання, а `0x02` представляє сучасний тип облікових даних для компаундингу. + +Валідатори з ключами BLS `0x00` повинні оновити ці облікові дані, щоб вони вказували на адресу виконання, для активації виплат надлишкового балансу або повного виведення коштів зі стейкінгу. Це можна зробити, надавши адресу виконання в даних депозиту під час початкової генерації ключа, _АБО_ використавши ключ виведення коштів пізніше для підписання та трансляції повідомлення `BLSToExecutionChange`. + +[Докладніше про облікові дані для виведення коштів валідатора](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### Ключ для виведення коштів {#withdrawal-key} + +Ключ для виведення коштів буде потрібен для оновлення облікових даних для виведення, щоб вони вказували на адресу виконання, якщо це не було встановлено під час початкового депозиту. Це дозволить розпочати обробку виплат надлишкового балансу, а також дозволить користувачам повністю вивести свої застейкані ETH. + +Так само, як і ключі валідатора, ключі для виведення коштів також складаються з двох компонентів: + +- **Приватний** ключ для виведення коштів +- **Відкритий** ключ для виведення коштів + +Втрата цього ключа до оновлення облікових даних для виведення до типу `0x01` означає втрату доступу до балансу валідатора. Валідатор все ще може підписувати атестації та блоки, оскільки ці дії вимагають приватного ключа валідатора, однак стимулів для цього практично немає, якщо ключі для виведення коштів втрачено. + +Розділення ключів валідатора та ключів облікового запису Ethereum дозволяє одному користувачеві запускати кілька валідаторів. + +![схема ключа валідатора](validator-key-schematic.png) + +**Примітка**: вихід із обов’язків стейкінгу та виведення балансу валідатора наразі вимагає підписання [повідомлення про добровільний вихід (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) ключем валідатора. Однак [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) — це пропозиція, яка в майбутньому дозволить користувачеві ініціювати вихід валідатора та виведення його балансу шляхом підписання повідомлень про вихід ключем для виведення коштів. Це зменшить припущення щодо довіри, дозволяючи стейкерам, які делегують ETH [постачальникам стейкінгу як послуги](/staking/saas/#what-is-staking-as-a-service), зберігати контроль над своїми коштами. + +## Отримання ключів із сид-фрази {#deriving-keys-from-seed} + +Якби кожні 32 застейкані ETH вимагали нового набору з 2 абсолютно незалежних ключів, керування ключами швидко стало б громіздким, особливо для користувачів, які запускають кілька валідаторів. Натомість, кілька ключів валідатора можна отримати з одного спільного секрету, і зберігання цього єдиного секрету надає доступ до кількох ключів валідатора. + +[Мнемоніки](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) та шляхи — це важливі функції, з якими користувачі часто стикаються, коли [отримують доступ](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) до своїх гаманців. Мнемоніка — це послідовність слів, яка діє як початкове зерно для приватного ключа. У поєднанні з додатковими даними мнемоніка генерує хеш, відомий як «майстер-ключ». Це можна уявити як корінь дерева. Гілки з цього кореня потім можна вивести за допомогою ієрархічного шляху, щоб дочірні вузли могли існувати як комбінації хешу їхнього батьківського вузла та їхнього індексу в дереві. Прочитайте про стандарти [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) та [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) для генерації ключів на основі мнемоніки. + +Ці шляхи мають таку структуру, яка буде знайома користувачам, що взаємодіяли з апаратними гаманцями: + +``` +m/44'/60'/0'/0` +``` + +Слеші в цьому шляху розділяють компоненти приватного ключа таким чином: + +``` +master_key / purpose / coin_type / account / change / address_index +``` + +Ця логіка дозволяє користувачам приєднувати якомога більше валідаторів до однієї **мнемонічної фрази**, оскільки корінь дерева може бути спільним, а диференціація може відбуватися на гілках. Користувач може **отримати будь-яку кількість ключів** із мнемонічної фрази. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +Кожна гілка розділяється символом `/`, тому `m/2` означає почати з майстер-ключа і слідувати гілкою 2. На схемі нижче одна мнемонічна фраза використовується для зберігання трьох ключів для виведення коштів, кожен з яких має два пов'язані валідатори. + +![логіка ключів валідатора](multiple-keys.png) + +## Для подальшого читання {#further-reading} + +- [Публікація в блозі Ethereum Foundation від Карла Бекхейзена](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333: генерація ключів BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: виходи, ініційовані рівнем виконання](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Масштабне керування ключами](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..0673535ab42 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Доказ частки проти підтвердження роботи" +description: "Порівняння механізмів консенсусу Ethereum на основі доказу частки та підтвердження роботи" +lang: uk +--- + +Коли Ethereum був запущений, механізм доказу частки все ще потребував багато досліджень і розробок, перш ніж його можна було б використовувати для захисту Ethereum. Підтвердження роботи було простішим механізмом, який уже був доведений Bitcoin, тобто основні розробники могли негайно його реалізувати, щоб запустити Ethereum. Щоб розробити доказ частки до рівня, коли його можна було б запровадити, знадобилося ще вісім років. + +На цій сторінці пояснюється причина переходу Ethereum з механізму підтвердження роботи на доказ частки та пов'язані з цим компроміси. + +## Безпека {#security} + +Дослідники Ethereum вважають доказ частки більш безпечним, ніж підтвердження роботи. Однак він був реалізований для реальної основної мережі Ethereum лише нещодавно, і він менш перевірений часом, ніж підтвердження роботи. У наступних розділах обговорюються плюси та мінуси моделі безпеки доказу частки в порівнянні з підтвердженням роботи. + +### Вартість атаки {#cost-to-attack} + +У механізмі доказу частки валідатори зобов'язані депонувати («внести в стейкінг») щонайменше 32 ETH у смарт-контракт. Ethereum може знищити етер у стейкінгу, щоб покарати валідаторів, які поводяться неправильно. Щоб досягти консенсусу, щонайменше 66 % усього етеру в стейкінгу має проголосувати за певний набір блоків. Блоки, за які проголосувало >=66% частки, стають «фіналізованими», тобто їх неможливо видалити або реорганізувати. + +Атака на мережу може означати перешкоджання фіналізації ланцюга або забезпечення певної організації блоків у канонічному ланцюзі, яка якимось чином приносить користь зловмиснику. Для цього зловмиснику потрібно змінити шлях чесного консенсусу, або накопичивши велику кількість етеру та проголосувавши ним безпосередньо, або обманом змусивши чесних валідаторів голосувати певним чином. Якщо не брати до уваги складні, малоймовірні атаки, які обманюють чесних валідаторів, вартість атаки на Ethereum — це вартість частки, яку зловмисник має накопичити, щоб вплинути на консенсус на свою користь. + +Найнижча вартість атаки становить >33 % від загальної частки. Зловмисник, який володіє >33% загальної частки, може спричинити затримку завершення, просто перейшовши в автономний режим. Це відносно незначна проблема для мережі, оскільки існує механізм, відомий як «витік через неактивність», який виводить частку з офлайн-валідаторів, доки онлайн-більшість не становитиме 66% частки й не зможе знову фіналізувати ланцюг. Теоретично зловмисник також може спричинити подвійне завершення, маючи трохи більше 33% від загальної частки, створивши два блоки замість одного, коли його попросять стати виробником блоку, а потім двічі проголосувати всіма своїми валідаторами. Кожен форк вимагає лише, щоб 50 % чесних валідаторів, що залишилися, спершу побачили кожен блок, тому, якщо їм вдасться точно розрахувати час своїх повідомлень, вони зможуть фіналізувати обидва форки. Це має низьку ймовірність успіху, але якби зловмисник зміг спричинити подвійне завершення, спільноті Ethereum довелося б вирішити слідувати одному форку, і в цьому випадку валідатори зловмисника обов’язково зазнали б слешингу на іншому. + +Маючи >33% від загальної частки, зловмисник має шанс здійснити незначний (затримка завершення) або більш серйозний (подвійне завершення) вплив на мережу Ethereum. Маючи понад 14 000 000 ETH у стейкінгу в мережі та репрезентативну ціну 1000 доларів США/ETH, мінімальна вартість проведення цих атак становить `1000 x 14 000 000 x 0,33 = 4 620 000 000 доларів США`. Зловмисник втратив би ці гроші через слешинг і був би виключений із мережі. Щоб атакувати знову, їм доведеться накопичити >33 % частки (знову) і спалити її (знову). Кожна спроба атакувати мережу коштуватиме >4,6 мільярда доларів США (за ціною 1000 доларів США/ETH і 14 мільйонів ETH у стейкінгу). Зловмисника також виключають із мережі, коли він зазнає слешингу, і він мусить приєднатися до черги активації, щоб знову приєднатися. Це означає, що швидкість повторної атаки обмежується не лише швидкістю, з якою зловмисник може накопичити >33% загальної частки, але й часом, необхідним для підключення всіх своїх валідаторів до мережі. Щоразу, коли зловмисник атакує, він стає набагато біднішим, а решта спільноти стає багатшою завдяки шоку пропозиції, що виникає в результаті. + +Інші атаки, такі як атаки 51% або скасування завершення з 66% від загальної частки, вимагають значно більше ETH і є набагато дорожчими для зловмисника. + +Порівняйте це з підтвердженням роботи. Вартість запуску атаки на Ethereum з механізмом підтвердження роботи дорівнювала вартості постійного володіння >50% від загального хешрейту мережі. Це дорівнювало витратам на обладнання та експлуатаційним витратам на достатню обчислювальну потужність, щоб випередити інших майнерів і постійно обчислювати рішення для підтвердження роботи. Майнінг Ethereum в основному здійснювався за допомогою графічних процесорів, а не ASIC, що дозволяло знизити витрати (хоча якби Ethereum залишився на механізмі підтвердження роботи, майнінг на ASIC міг би стати більш популярним). Супротивнику довелося б придбати багато обладнання та заплатити за електроенергію для його роботи, щоб атакувати мережу Ethereum з механізмом підтвердження роботи, але загальна вартість була б меншою за вартість, необхідну для накопичення достатньої кількості ETH для початку атаки. Атака 51% приблизно ~[у 20 разів дешевша](https://youtu.be/1m12zgJ42dI?t=1562) на механізмі підтвердження роботи, ніж на механізмі доказу частки. Якби атака була виявлена і для видалення їхніх змін був би проведений хард-форк ланцюга, зловмисник міг би неодноразово використовувати те саме обладнання для атаки на новий форк. + +### Складність {#complexity} + +Доказ частки набагато складніший, ніж підтвердження роботи. Це може бути аргументом на користь підтвердження роботи, оскільки в простіші протоколи важче випадково внести помилки або непередбачені ефекти. Однак складність вдалося приборкати роками досліджень і розробок, симуляцій та впроваджень у тестових мережах. Протокол доказу частки був незалежно реалізований п’ятьма окремими командами (на кожному з шарів виконання та консенсусу) п’ятьма мовами програмування, що забезпечує стійкість до помилок клієнта. + +Щоб безпечно розробити та протестувати логіку консенсусу доказу частки, Beacon Chain було запущено за два роки до того, як доказ частки було реалізовано в основній мережі Ethereum. Beacon Chain діяв як пісочниця для тестування доказу частки, оскільки це був живий блокчейн, що реалізовував логіку консенсусу доказу частки, але не торкався реальних транзакцій Ethereum — по суті, просто досягаючи консенсусу щодо себе. Після того, як він був стабільним і без помилок протягом достатнього часу, Beacon Chain було «об’єднано» з основною мережею Ethereum. Все це сприяло приборканню складності доказу частки до такого рівня, що ризик непередбачених наслідків або помилок клієнта став дуже низьким. + +### Поверхня атаки {#attack-surface} + +Доказ частки складніший за підтвердження роботи, що означає, що є більше потенційних векторів атак, з якими потрібно боротися. Замість однієї однорангової мережі, що з’єднує клієнтів, є дві, кожна з яких реалізує окремий протокол. Наявність одного конкретного валідатора, попередньо обраного для пропозиції блоку в кожному слоті, створює потенціал для відмови в обслуговуванні, коли великі обсяги мережевого трафіку виводять цього конкретного валідатора з мережі. + +Існують також способи, якими зловмисники можуть ретельно розраховувати час випуску своїх блоків або атестацій, щоб вони були отримані певною частиною чесної мережі, впливаючи на них, щоб голосувати певним чином. Нарешті, зловмисник може просто накопичити достатньо ETH для стейкінгу та домінувати в механізмі консенсусу. Кожен із цих [векторів атак має відповідні засоби захисту](/developers/docs/consensus-mechanisms/pos/attack-and-defense), але їх не потрібно захищати в механізмі підтвердження роботи. + +## Децентралізація {#decentralization} + +Доказ частки є більш децентралізованим, ніж підтвердження роботи, оскільки гонка озброєнь обладнання для майнінгу, як правило, витісняє приватних осіб і невеликі організації. Хоча технічно будь-хто може почати майнінг зі скромним обладнанням, імовірність отримання будь-якої винагороди є мізерно малою порівняно з інституційними майнінговими операціями. Завдяки доказу частки вартість стейкінгу та відсотковий дохід від цієї частки є однаковими для всіх. Зараз для запуску валідатора потрібно 32 ETH. + +З іншого боку, винахід деривативів ліквідного стейкінгу викликав занепокоєння щодо централізації, оскільки кілька великих провайдерів керують великими обсягами ETH у стейкінгу. Це проблематично і потребує якнайшвидшого виправлення, але це також більш тонке питання, ніж здається. Централізовані провайдери стейкінгу не обов’язково мають централізований контроль над валідаторами — часто це просто спосіб створити центральний пул ETH, який багато незалежних операторів вузлів можуть вносити в стейкінг без необхідності, щоб кожен учасник мав 32 власних ETH. + +Найкращий варіант для Ethereum — це коли валідатори запускаються локально на домашніх комп’ютерах, що максимізує децентралізацію. Ось чому Ethereum протистоїть змінам, які підвищують вимоги до обладнання для запуску вузла/валідатора. + +## Сталість {#sustainability} + +Доказ частки — це дешевий з точки зору викидів вуглецю спосіб захисту блокчейну. У механізмі підтвердження роботи майнери змагаються за право майнити блок. Майнери є більш успішними, коли вони можуть виконувати обчислення швидше, що стимулює інвестиції в обладнання та споживання енергії. Це спостерігалося для Ethereum до переходу на доказ частки. Незадовго до переходу на доказ частки Ethereum споживав приблизно 78 ТВт·год/рік — стільки ж, скільки невелика країна. Однак перехід на доказ частки зменшив ці витрати енергії на ~99,98%. Доказ частки зробив Ethereum енергоефективною платформою з низьким рівнем викидів вуглецю. + +[Більше про споживання енергії Ethereum](/energy-consumption) + +## Емісія {#issuance} + +Ethereum з механізмом доказу частки може платити за свою безпеку, випускаючи набагато менше монет, ніж Ethereum з механізмом підтвердження роботи, оскільки валідаторам не потрібно платити високі рахунки за електроенергію. В результаті ETH може знизити свою інфляцію або навіть стати дефляційним, коли спалюється велика кількість ETH. Нижчі рівні інфляції означають, що безпека Ethereum є дешевшою, ніж за часів підтвердження роботи. + +## Цікавить наочний матеріал? Для тих, хто навчається візуально {#visual-learner} + +Подивіться, як Джастін Дрейк пояснює переваги доказу частки над підтвердженням роботи: + + + +## Для подальшого читання {#further-reading} + +- [Філософія дизайну доказу частки Віталіка](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Поширені запитання Віталіка про доказ частки](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Відео «Просто пояснено» про PoS проти PoW](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..1cd5fa8d536 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "Винагороди та штрафи за доказом частки" +description: "Дізнайтеся про внутрішньопротокольні стимули в Ethereum на основі доказу частки." +lang: uk +--- + +Безпека Ethereum забезпечується за допомогою його власної криптовалюти - ефіру (ETH). Оператори вузлів, які бажають брати участь у валідації блоків і визначенні голови ланцюжка, вносять Ether у [депозитний контракт](/staking/deposit-contract/) в мережі Ethereum. Потім їм платять ефіром за запуск програмного забезпечення-валідатора, яке перевіряє дійсність нових блоків, отриманих через пірингову мережу, і застосовує алгоритм вибору виделки для визначення голови ланцюжка. + +Валідатор виконує дві основні ролі: 1) перевірка нових блоків і "засвідчення" їхньої валідності, 2) пропонування нових блоків при випадковому виборі із загального пулу валідаторів. Якщо валідатор не виконає жодного з цих завдань, він не отримає виплату ефіру. Іноді валідаторам також доручають збирати підписи та брати участь у синхронізаційних комітетах. + +Існують також деякі дії, які дуже важко зробити випадково і які свідчать про зловмисні наміри, наприклад, пропозиція декількох блоків для одного слоту або підтвердження декількох блоків для одного слоту. Так звана піддатлива до зменшення поведінка призводить до того, що валідатор спалює деяку кількість ефіру (до 1 ETH) до того, як валідатора буде видалено з мережі, що триває 36 днів. Ефір скороченого валідатора повільно стікає протягом періоду виходу, але на 18-ий день вони отримують «кореляційний штраф», який стає більшим, коли більше валідаторів скорочуються приблизно в той самий час. Таким чином, структура стимулів механізму консенсусу платить за чесність і карає поганих гравців. + +Всі нагороди та покарання застосовуються один раз за епоху. + +Читайте далі, щоб дізнатися більше... + +## Винагороди та штрафи {#rewards} + +### Винагороди {#rewards} + +Валідатори отримують винагороду, коли вони голосують так, як більшість інших валідаторів, коли вони пропонують блоки і коли вони беруть участь у комітетах синхронізації. Розмір винагород у кожну епоху розраховується на основі `base_reward`. Це базова одиниця, від якої розраховуються інші винагороди. `base_reward` — це середня винагорода, яку отримує валідатор за оптимальних умов за епоху. Він розраховується на основі ефективного балансу валідатора та загальної кількості активних валідаторів таким чином: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +де `base_reward_factor` — це 64, `base_rewards_per_epoch` — 4, а `sum(active balance)` — це загальна сума застейканого Ether для всіх активних валідаторів. + +Це означає, що базова винагорода пропорційна ефективному балансу валідатора та обернено пропорційна кількості валідаторів у мережі. Чим більше валідаторів, тим більший загальний випуск (як `sqrt(N)`), але тим менший `base_reward` на валідатора (як `1/sqrt(N)`). Ці фактори впливають на APR для вузла стейкінгу. Прочитайте обґрунтування цього в [записах Віталіка](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +Загальна винагорода розраховується як сума п'яти компонентів, кожен з яких має вагу, що визначає, скільки кожен компонент додає до загальної винагороди. Цими компонентами є: + +``` +1. source vote: the validator has made a timely vote for the correct source checkpoint +2. target vote: the validator has made a timely vote for the correct target checkpoint +3. head vote: the validator has made a timely vote for the correct head block +4. sync committee reward: the validator has participated in a sync committee +5. proposer reward: the validator has proposed a block in the correct slot +``` + +Вагові коефіцієнти для кожного компонента є наступними: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +Сума цих вагових коефіцієнтів дорівнює 64. Винагорода розраховується як сума відповідних вагових коефіцієнтів, поділена на 64. Валідатор, який своєчасно проголосував за джерело, ціль і голову, запропонував блок і взяв участь у комітеті синхронізації, може отримати `64/64 * base_reward == base_reward`. Однак зазвичай валідатор не є автором пропозиції блоку, тому його максимальна винагорода становить `64-8 /64 * base_reward == 7/8 * base_reward`. Валідатори, які не є ані авторами пропозицій блоків, ані членами комітету синхронізації, можуть отримати `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. + +Додаткова винагорода додається для стимулювання швидкого проходження атестації. Це і є `inclusion_delay_reward`. Це значення дорівнює `base_reward`, помноженому на `1/delay`, де `delay` — це кількість слотів між пропозицією блоку та атестацією. Наприклад, якщо атестація подається в межах одного слоту від пропозиції блоку, атестувальник отримує `base_reward * 1/1 == base_reward`. Якщо атестація надходить у наступному слоті, атестувальник отримує `base_reward * 1/2` і так далі. + +Автори пропозицій блоків отримують `8 / 64 * base_reward` за **кожну дійсну атестацію**, включену в блок, тому фактичний розмір винагороди масштабується залежно від кількості валідаторів, що атестують. Автори пропозицій блоків також можуть збільшити свою винагороду, включивши докази неправомірної поведінки інших валідаторів у свій запропонований блок. Ці винагороди — це «пряники», які заохочують чесність валідаторів. Автор пропозиції блоку, що включає слешинг, буде винагороджений сумою `slashed_validators_effective_balance / 512`. + +### Штрафи {#penalties} + +Досі ми розглядали валідаторів, які поводяться ідеально, але як щодо валідаторів, які не голосують своєчасно за голову, джерело та ціль або роблять це повільно? + +Штрафи за пропуск голосувань за ціль і джерело дорівнюють винагородам, які атестувальник отримав би, якби подав їх. Це означає, що замість додавання винагороди до їхнього балансу, з їхнього балансу знімається еквівалентна сума. За пропуск голосування за голову штраф не стягується (тобто голосування за голову лише винагороджуються, але ніколи не штрафуються). Штраф, пов’язаний із `inclusion_delay`, відсутній — винагорода просто не буде додана до балансу валідатора. Також немає штрафу за невдалу пропозицію блоку. + +Дізнайтеся більше про винагороди та штрафи в [специфікаціях консенсусу](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Винагороди та штрафи були скориговані в оновленні Bellatrix — дивіться, як Денні Раян і Віталік обговорюють це у відео [Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). + +## Слешинг {#slashing} + +Слешинг — це більш сувора дія, яка призводить до примусового вилучення валідатора з мережі та пов’язаної з цим втрати його застейканого Ether. Існує три способи, як валідатор може бути підданий слешингу, і всі вони зводяться до нечесної пропозиції або атестації блоків: + +- Пропозиція та підписання двох різних блоків для одного й того ж слоту. +- Атестація блоку, що "оточує" інший (фактично змінюючи історію). +- Шляхом "подвійного голосування" через атестацію двох кандидатів на один і той же блок. + +Якщо ці дії будуть виявлені, валідатор буде підданий слешингу. Це означає, що 0,0078125 негайно спалюється для валідатора з 32 ETH (лінійно масштабується з активним балансом), після чого починається 36-денний період вилучення. Протягом цього періоду вилучення частка валідатора поступово зменшується. У середині періоду (на 18-й день) застосовується додатковий штраф, розмір якого залежить від загальної суми застейканого Ether усіх валідаторів, підданих слешингу за 36 днів до події слешингу. Це означає, що чим більше валідаторів піддаються слешингу, тим більшим є його розмір. Максимальний слешинг — це повний ефективний баланс усіх валідаторів, які були піддані слешингу (тобто, якщо слешингу піддається багато валідаторів, вони можуть втратити всю свою частку). З іншого боку, одна окрема подія слешингу спалює лише невелику частину частки валідатора. Цей проміжний штраф, що масштабується з кількістю валідаторів, підданих слешингу, називається "кореляційним штрафом". + +## Витік через неактивність {#inactivity-leak} + +Якщо на шарі консенсусу протягом більш ніж чотирьох епох не відбувається фіналізація, активується екстрений протокол під назвою "витік через неактивність". Кінцевою метою витоку через неактивність є створення умов, необхідних для відновлення фіналізації ланцюжка. Як пояснювалося вище, для фіналізації потрібна згода більшості у 2/3 від загальної кількості застейканого Ether щодо вихідної та цільової контрольних точок. Якщо валідатори, що представляють понад 1/3 від загальної кількості валідаторів, виходять з мережі або не подають правильні атестації, то супербільшість у 2/3 не може фіналізувати контрольні точки. Витік через неактивність дозволяє частці неактивних валідаторів поступово зменшуватися, доки вони не контролюватимуть менше 1/3 загальної частки, що дозволить решті активних валідаторів фіналізувати ланцюжок. Незалежно від розміру пулу неактивних валідаторів, решта активних валідаторів зрештою контролюватиме >2/3 частки. Втрата частки є сильним стимулом для неактивних валідаторів якнайшвидше відновити активність! Сценарій витоку через неактивність стався в тестовій мережі Medalla, коли менше ніж 66 % активних валідаторів змогли досягти консенсусу щодо поточної голови блокчейну. Було активовано витік через неактивність, і фіналізацію зрештою було відновлено! + +Дизайн винагород, штрафів і слешингу в механізмі консенсусу заохочує окремих валідаторів поводитися правильно. Однак із цих проектних рішень виникає система, яка сильно стимулює рівномірний розподіл валідаторів між кількома клієнтами та має сильно перешкоджати домінуванню одного клієнта. + +## Для подальшого читання {#further-reading} + +- [Оновлення Ethereum: стимулюючий шар](https://eth2book.info/altair/part2/incentives) +- [Стимули в гібридному протоколі Casper Ethereum](https://arxiv.org/pdf/1903.04205.pdf) +- [Анотована специфікація Віталіка](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Поради щодо запобігання слешингу в Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Аналіз штрафів за слешинг згідно з EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_Джерела_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..7bc852288ba --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "Слабка суб'єктивність" +description: "Пояснення слабкої суб’єктивності та її ролі в PoS Ethereum." +lang: uk +--- + +Суб’єктивність у блокчейнах означає залежність від соціальної інформації для узгодження поточного стану. Може бути кілька дійсних розгалужень, які вибираються відповідно до інформації, зібраної від інших однорангових вузлів у мережі. Зворотним є об’єктивність, яка стосується ланцюгів, де існує лише один можливий дійсний ланцюг, з яким усі вузли обов’язково погодяться, застосовуючи свої кодовані правила. Існує також третій стан, відомий як слабка суб'єктивність. Це відноситься до ланцюга, який може прогресувати об’єктивно після того, як деяке початкове насіння інформації буде отримано соціально. + +## Передумови {#prerequisites} + +Щоб зрозуміти цю сторінку, необхідно спершу розібратися з основами [доказу частки](/developers/docs/consensus-mechanisms/pos/). + +## Які проблеми вирішує слабка суб’єктивність? {#problems-ws-solves} + +Суб’єктивність притаманна блокчейнам із підтвердженням частки, оскільки вибір правильного ланцюга з кількох форків здійснюється шляхом підрахунку історичних голосів. Це наражає блокчейн на декілька векторів атак, включаючи атаки на великій відстані, за допомогою яких вузли, які брали участь на дуже ранніх етапах ланцюга, зберігають альтернативний форк, який вони випускають набагато пізніше для власної вигоди. Крім того, якщо 33% валідаторів відкликають свою частку, але продовжуватимуть засвідчувати та виробляти блоки, вони можуть створити альтернативний форк, який конфліктуватиме з канонічним ланцюгом. Нові вузли або вузли, які були офлайн протягом тривалого часу, можуть не знати, що ці атакуючі валідатори вилучили їхні кошти, тому зловмисники можуть обманом змусити їх слідувати неправильним ланцюжком. Ethereum може вирішити ці вектори атак, наклавши обмеження, які зменшують суб’єктивні аспекти механізму — і, отже, довірливі припущення — до мінімуму. + +## Контрольні точки слабкої суб'єктивності {#ws-checkpoints} + +Слабка суб’єктивність реалізована в proof-of-stake Ethereum за допомогою «контрольних точок слабкої суб’єктивності». Це корені стану, які всі вузли в мережі погоджуються належати до канонічного ланцюга. Вони служать тій самій меті «універсальної істини», що й генезис-блоки, за винятком того, що вони не знаходяться на початковій позиції в блокчейні. Алгоритм вибору форка вірить, що стан блокчейну, визначений у цій контрольній точці, є правильним, і що він незалежно та об’єктивно перевіряє ланцюжок з цієї точки і далі. Контрольні точки діють як «ліміти повернення», оскільки блоки, розташовані перед контрольними точками слабкої суб’єктивності, не можуть бути змінені. Це підриває далекі атаки, просто визначаючи далекобійні вилки недійсними як частину конструкції механізму. Забезпечення того, що контрольні точки слабкої суб’єктивності розділені на меншу відстань, ніж період виведення валідатора, гарантує, що валідатор, який розгалужує ланцюжок, скорочує принаймні деяку порогову суму, перш ніж він зможе зняти свою ставку, і що нові учасники не можуть бути обмануті валідаторами на неправильні розгалуження. чия частка була вилучена. + +## Різниця між контрольними точками слабкої суб'єктивності та завершеними блоками {#difference-between-ws-and-finalized-blocks} + +Завершені блоки та слабкі контрольні точки суб’єктивності обробляються вузлами Ethereum по-різному. Якщо вузол дізнається про два конкуруючих фіналізованих блоки, то він розривається між ними – він не має можливості автоматично визначити, який є канонічним форком. Це є симптомом провалу консенсусу. Навпаки, вузол просто відхиляє будь-який блок, який конфліктує з його слабкою контрольною точкою суб’єктивності. З точки зору вузла, слабка контрольна точка суб’єктивності представляє абсолютну істину, яка не може бути підірвана новими знаннями від однолітків. + +## Наскільки слабкий слабкий? Як можна конвертувати Eth після хардфорку? {#how-weak-is-weak} + +Суб’єктивний аспект підтвердження частки Ethereum — це вимога до останнього стану (контрольна точка слабкої суб’єктивності) від надійного джерела для синхронізації. Ризик отримати погану слабку контрольну точку суб’єктивності дуже низький, оскільки їх можна перевірити за кількома незалежними загальнодоступними джерелами, такими як дослідники блоків або кілька вузлів. Однак для запуску будь-якого програмного забезпечення завжди необхідний певний ступінь довіри, наприклад, віра в те, що розробники програмного забезпечення створили чесне програмне забезпечення. + +Слабка контрольна точка суб’єктивності може навіть бути частиною клієнтського програмного забезпечення. Можливо, зловмисник може пошкодити контрольну точку в програмному забезпеченні та так само легко пошкодити саме програмне забезпечення. Немає реального криптоекономічного шляху вирішення цієї проблеми, але вплив ненадійних розробників мінімізований в Ethereum завдяки наявності кількох незалежних команд клієнтів, кожна з яких створює еквівалентне програмне забезпечення різними мовами, і всі вони зацікавлені в підтримці чесного ланцюжка. Провідники блоків також можуть надавати слабкі контрольні точки суб’єктивності або спосіб перехресного посилання на контрольні точки, отримані з інших джерел, із додатковим джерелом. + +Нарешті, контрольні точки можна запитувати з інших вузлів; можливо, інший користувач Ethereum, який запускає повний вузол, може надати контрольну точку, яку валідатори можуть потім перевірити за даними з провідника блоків. Загалом довіряти постачальнику слабкої контрольної точки суб’єктивності можна вважати такою ж проблематичною, як довіряти клієнтським розробникам. Загальна необхідна довіра низька. Важливо відзначити, що ці міркування стають важливими лише в тому малоймовірному випадку, коли більшість валідаторів змовляються створити альтернативний форк блокчейну. За будь-яких інших обставин є лише один ланцюжок Ethereum на вибір. + +## Додаткові матеріали {#further-reading} + +- [Слабка суб'єктивність в Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Віталік: як я полюбив слабку суб'єктивність](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Слабка суб'єктивність (документація Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Посібник зі слабкої суб'єктивності для Фази 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Аналіз слабкої суб'єктивності в Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..c1a34a584fc --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "Облікові дані для виведення" +description: "Пояснення типів облікових даних валідатора для виведення коштів (0x00, 0x01, 0x02) та їхніх наслідків для стейкерів Ethereum." +lang: uk +--- + +Кожен валідатор має **облікові дані для виведення коштів**, які визначають, як і куди можна вивести його ETH у стейкінгу та винагороди. Тип облікових даних позначається першим байтом: `0x00`, `0x01` або `0x02`. Розуміння цих типів є важливим для валідаторів, які керують своїм стейком. + +## 0x00: Облікові дані до оновлення Shapella {#0x00-credentials} + +Тип `0x00` — це оригінальний формат облікових даних для виведення коштів до оновлення Shapella (квітень 2023 р.). Валідатори з цим типом облікових даних не мають встановленої адреси для виведення коштів на рівні виконання, що означає, що їхні кошти залишаються заблокованими на рівні консенсусу. Якщо у вас усе ще облікові дані `0x00`, ви повинні оновитися до `0x01` або `0x02`, перш ніж зможете отримувати будь-які виведені кошти. + +## 0x01: Застарілі облікові дані для виведення коштів {#0x01-credentials} + +Тип `0x01` був запроваджений з оновленням Shapella і став стандартом для валідаторів, які хотіли встановити адресу для виведення коштів на рівні виконання. З обліковими даними `0x01`: + +- Будь-який баланс понад 32 ETH **автоматично переказується** на вашу адресу для виведення коштів +- Повні виходи проходять через стандартну чергу виходу +- Винагороди понад 32 ETH не можуть капіталізуватися — вони періодично виводяться + +**Чому деякі валідатори досі використовують 0x01:** це простіше і звичніше. Багато валідаторів зробили депозит після Shapella і вже мають цей тип, і він добре працює для тих, хто хоче автоматично виводити надлишок балансу. + +**Чому це не рекомендується:** з `0x01` ви втрачаєте можливість капіталізувати винагороди понад 32 ETH. Кожен надлишок автоматично виводиться, що обмежує потенціал заробітку вашого валідатора та вимагає окремого керування виведеними коштами. + +## 0x02: Облікові дані для виведення коштів з капіталізацією {#0x02-credentials} + +Тип `0x02` був запроваджений з оновленням Pectra і є **рекомендованим вибором** для валідаторів на сьогоднішній день. Валідаторів з обліковими даними `0x02` іноді називають «валідаторами з капіталізацією». + +З обліковими даними `0x02`: + +- Винагороди понад 32 ETH **капіталізуються** з кроком в 1 ETH до максимального ефективного балансу 2048 ETH +- Часткове виведення коштів потрібно запитувати вручну (автоматичне виведення відбувається лише за перевищення порогу в 2048 ETH) +- Валідатори можуть об'єднувати кілька валідаторів з 32 ETH в одного валідатора з вищим балансом +- Повні виходи все ще підтримуються через стандартну чергу виходу + +Як часткове виведення коштів, так і об'єднання можна виконати через розділ [Дії валідатора на Стартовій платформі](https://launchpad.ethereum.org/en/validator-actions). + +**Чому валідаторам варто віддавати перевагу 0x02:** він пропонує кращу ефективність капіталу завдяки капіталізації, більше контролю над виведенням коштів і підтримує об'єднання валідаторів. Для соло-стейкерів, які з часом накопичують винагороди, це означає, що їхній ефективний баланс, а отже, і винагороди, можуть зростати понад 32 ETH без ручного втручання. + +**Важливо:** після переходу з `0x01` на `0x02` ви не зможете повернутися назад. + +Щоб отримати докладний посібник із переходу на облікові дані типу 2 та функцію MaxEB, див. [сторінку з поясненням MaxEB](/roadmap/pectra/maxeb/). + +## Що мені вибрати? {#what-should-i-pick} + +- **Нові валідатори:** вибирайте `0x02`. Це сучасний стандарт із кращою капіталізацією та гнучкістю. +- **Наявні валідатори 0x01:** розгляньте можливість переходу на `0x02`, якщо ви хочете, щоб винагороди капіталізувалися понад 32 ETH, або плануєте об'єднувати валідаторів. +- **Наявні валідатори 0x00:** оновіться негайно — ви не зможете вивести кошти, не оновивши свої облікові дані. Спочатку потрібно перейти на `0x01`, а потім можна перейти на `0x02`. + +## Інструменти для керування обліковими даними для виведення коштів {#withdrawal-credential-tools} + +Декілька інструментів підтримують вибір або перехід між типами облікових даних: + +- **[Стартова платформа для стейкінгу Ethereum](https://launchpad.ethereum.org/en/validator-actions)** — офіційний інструмент для депозитів та керування валідаторами, включно з перетворенням облікових даних та об'єднаннями +- **[Pectra Staking Manager](https://pectrastaking.com)** — вебінтерфейс із підтримкою WalletConnect для перетворень та об'єднання +- **[Інструмент CLI Pectra Validator Ops](https://github.com/Luganodes/Pectra-Batch-Contract)** — інструмент командного рядка для пакетних перетворень +- **[Ethereal](https://github.com/wealdtech/ethereal)** — інструмент командного рядка для операцій Ethereum, включно з керуванням валідаторами + +Щоб отримати повний список інструментів для об'єднання та детальні інструкції з перетворення, див. [Інструменти для об'єднання MaxEB](/roadmap/pectra/maxeb/#consolidation-tooling). + +## Для подальшого читання {#further-reading} + +- [Ключі в Ethereum на доказі частки](/developers/docs/consensus-mechanisms/pos/keys/) — дізнайтеся про ключі валідатора та їхній зв'язок з обліковими даними для виведення коштів +- [MaxEB](/roadmap/pectra/maxeb/) — докладний посібник з оновлення Pectra та функції максимального ефективного балансу diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..92168c7e43a --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: Proof-of-work (PoW) +description: "Пояснення протоколу консенсусу proof-of-work та його ролі в Ethereum." +lang: uk +--- + +Мережа Ethereum почала з використання механізму консенсусу, який передбачав **[підтвердження роботи (PoW)](/developers/docs/consensus-mechanisms/pow)**. Це дозволяло вузлам мережі Ethereum узгоджувати стан усієї інформації, записаної в блокчейні Ethereum, і запобігало певним видам економічних атак. Однак у 2022 році Ethereum відмовився від підтвердження роботи й натомість почав використовувати [доказ частки](/developers/docs/consensus-mechanisms/pos). + + + + + + Підтвердження роботи зараз застаріло. Ethereum більше не використовує підтвердження роботи як частину свого механізму консенсусу. Натомість використовується доказ частки. Дізнайтеся більше про [доказ частки](/developers/docs/consensus-mechanisms/pos/) та [стейкінг](/staking/). + + + + +## Передумови {#prerequisites} + +Щоб краще зрозуміти цю сторінку, рекомендуємо спочатку ознайомитися з [транзакціями](/developers/docs/transactions/), [блоками](/developers/docs/blocks/) та [механізмами консенсусу](/developers/docs/consensus-mechanisms/). + +## Що таке Proof-of-work (PoW)? {#what-is-pow} + +Консенсус Накамото, який використовує підтвердження роботи, — це механізм, який колись дозволяв децентралізованій мережі Ethereum досягати консенсусу (тобто всі вузли погоджуються) щодо таких речей, як баланси рахунків і порядок транзакцій. Це не дозволяло користувачам здійснювати "подвійні витрати" своїх монет і гарантувало, що ланцюжок Ethereum було надзвичайно важко атакувати чи маніпулювати ним. Тепер ці властивості безпеки натомість забезпечуються доказом частки з використанням механізму консенсусу, відомого як [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). + +## Підтвердження роботи та майнінг {#pow-and-mining} + +Підтвердження роботи — це базовий алгоритм, який встановлює складність і правила для роботи, яку виконують майнери в блокчейнах на основі підтвердження роботи. Майнінг - це сама «робота». Це акт додавання дійсних блоків до ланцюжка. Це важливо, оскільки довжина ланцюжка допомагає мережі слідувати правильному форку блокчейну. Чим більше "роботи" зроблено, чим довший ланцюжок, і чим вище номер блоку, тим більш певною може бути мережа щодо поточного стану речей. + +[Докладніше про майнінг](/developers/docs/consensus-mechanisms/pow/mining/) + +## Як працював механізм підтвердження роботи Ethereum? {#how-it-works} + +Транзакції Ethereum обробляються в блоки. У застарілому механізмі підтвердження роботи Ethereum кожен блок містив: + +- складність блоку – наприклад: 3,324,092,183,262,715 +- mixHash — наприклад: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce — наприклад: `0xd3ee432b4fb3d26b` + +Ці дані блоку були безпосередньо пов’язані з підтвердженням роботи. + +### Робота в механізмі підтвердження роботи {#the-work} + +Протокол підтвердження роботи Ethash вимагав від майнерів брати участь в інтенсивній гонці спроб і помилок, щоб знайти nonce для блоку. Лише блоки з дійсним nonce могли бути додані до ланцюжка. + +У гонці за створення блоку майнер неодноразово пропускав набір даних, який можна було отримати, лише завантаживши та запустивши повний ланцюжок (як це робить майнер), через математичну функцію. Набір даних використовувався для генерації mixHash нижче цільового значення, яке визначалося складністю блоку. Набір даних використовується для генерування mixHash нижче цільового одноразового номера, що диктується складністю блоку. + +Складність визначала цільове значення для хешу. Чим нижча ціль, тим менший набір дійсних хешів. Після створення це було неймовірно легко перевірити іншим майнерам і клієнтам. Навіть якби одна транзакція змінилася, хеш був би зовсім іншим, сигналізуючи про шахрайство. + +Хешування дозволяє легко виявити шахрайство. Але підтвердження роботи як процес також було значним стримувальним фактором для атаки на ланцюжок. + +### Підтвердження роботи та безпека {#security} + +Майнери були зацікавлені виконувати цю роботу в основному ланцюжку Ethereum. У підгрупи майнерів було мало стимулів створювати власний ланцюжок — це підриває систему. Блокчейни покладаються на наявність єдиної держави як джерела істини. + +Метою підтвердження роботи було розширення ланцюжка. Найдовший ланцюжок вважався найбільш достовірним як дійсний, оскільки для його створення було виконано найбільше обчислювальної роботи. У системі PoW мережі Ethereum було майже неможливо створювати нові блоки, які стирають транзакції, створюють підроблені або підтримують другий ланцюжок. Це тому, що зловмисному майнеру потрібно було б завжди знаходити nonce блоку швидше, ніж усі інші. + +Щоб постійно створювати зловмисні, але дійсні блоки, зловмисному майнеру знадобилося б понад 51% майнінгової потужності мережі, щоб випередити всіх інших. Такий обсяг "роботи" вимагав великої кількості дорогої обчислювальної потужності, і витрачена енергія могла б навіть перевищити вигоду, отриману від атаки. + +### Економіка підтвердження роботи {#economics} + +Підтвердження роботи також відповідало за введення нової валюти в систему та стимулювання майнерів до виконання роботи. + +Після [оновлення Constantinople](/ethereum-forks/#constantinople) майнери, які успішно створювали блок, отримували винагороду у вигляді двох щойно викарбуваних ETH і частини комісій за транзакції. Блоки Ommer також компенсували 1,75 ETH. Блоки Ommer були дійсними блоками, створеними одним майнером практично одночасно з тим, як інший майнер створив канонічний блок, що в кінцевому підсумку визначалося тим, на якому ланцюжку було побудовано перший наступний блок. Блоки Ommer зазвичай з’являлися через затримку в мережі. + +## Завершеність {#finality} + +Транзакція має "кінцевість" в Ethereum, коли вона є частиною блоку, який не може змінитися. + +Оскільки майнери працювали децентралізовано, два дійсні блоки могли бути видобуті одночасно. Це створює тимчасову розгалуження. Зрештою, один із цих ланцюжків ставав прийнятим після того, як наступні блоки були видобуті та додані до нього, що робило його довшим. + +Щоб ще більше ускладнити ситуацію, транзакції, відхилені в тимчасовому форку, могли не бути включені до прийнятого ланцюжка. Це означає, що його можна змінити. Таким чином, остаточність відноситься до часу, який ви повинні чекати, перш ніж вважати транзакцію незворотною. У попередньому механізмі підтвердження роботи Ethereum, чим більше блоків видобувалося поверх певного блоку `N`, тим вищою була впевненість у тому, що транзакції в `N` були успішними та не будуть скасовані. Тепер, з доказом частки, завершеність є явною, а не імовірнісною властивістю блоку. + +## Енергоспоживання підтвердження роботи {#energy} + +Серйозною критикою доказів роботи є кількість енергії, необхідної для забезпечення безпеки мережі. Для підтримки безпеки та децентралізації Ethereum на основі підтвердження роботи споживав велику кількість енергії. Незадовго до переходу на доказ частки майнери Ethereum спільно споживали близько 70 ТВт·год/рік (приблизно стільки ж, скільки Чеська Республіка — за даними [digiconomist](https://digiconomist.net/) станом на 18 липня 2022 року). + +## Переваги та недоліки {#pros-and-cons} + +| Переваги | Недоліки | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Доказ виконаної роботи є нейтральним. Вам не потрібен ETH, щоб почати, а нагороди за блокування дозволяють перейти від 0 ETH до позитивного балансу. З [доказом частки](/developers/docs/consensus-mechanisms/pos/) для початку вам потрібні ETH. | Доказ роботи споживає стільки енергії, що це шкідливо для навколишнього середовища. | +| Proof-of-work — це перевірений механізм консенсусу, який протягом багатьох років забезпечував захист і децентралізацію Bitcoin та Ethereum. | Якщо ви хочете займатися видобутком, вам потрібне таке спеціалізоване обладнання, що для початку це великі інвестиції. | +| У порівнянні з proof-of-stake його відносно легко реалізувати. | Через збільшення кількості необхідних обчислень майнінгові пули потенційно можуть домінувати в грі, що призведе до централізації та ризиків безпеки. | + +## Порівняння з доказом частки {#compared-to-pos} + +На високому рівні proof-of-stake має ту ж кінцеву мету, що й proof-of-work: допомогти децентралізованій мережі безпечно досягти консенсусу. Але він має деякі відмінності в процесі та персоналі: + +- Підтвердження ставки вимикає важливість обчислювальної потужності для ставок ETH. +- Підтвердження ставки замінює майнерів валідаторами. Валідатори ставлять свій ETH, щоб активувати можливість створення нових блоків. +- Валідатори не змагаються за створення блоків, натомість вони вибираються випадковим чином за допомогою алгоритму. +- Кінцевість зрозуміліша: на певних контрольних точках, якщо 2/3 валідаторів погоджуються щодо стану блоку, це вважається остаточним. Валідатори повинні поставити на це всю свою ставку, тому, якщо вони спробують вступити в змову, вони втратять всю свою ставку. + +[Докладніше про доказ частки](/developers/docs/consensus-mechanisms/pos/) + +## Цікавить наочний матеріал? Для тих, хто навчається візуально {#visual-learner} + + + +## Додаткові матеріали {#further-reading} + +- [Атака більшості](https://en.bitcoin.it/wiki/Majority_attack) +- [Про завершеність розрахунків](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### Відео {#videos} + +- [Технічне пояснення протоколів підтвердження роботи](https://youtu.be/9V1bipPkCTU) + +## Пов'язані теми {#related-topics} + +- [Майнінг](/developers/docs/consensus-mechanisms/pow/mining/) +- [Доказ частки](/developers/docs/consensus-mechanisms/pos/) +- [Доказ повноважень](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..f0a0b15fc27 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: Mining +description: "Пояснення того, як працював майнінг в Ethereum." +lang: uk +--- + + + + + +Підтвердження роботи більше не лежить в основі механізму консенсусу Ethereum, що означає, що майнінг було вимкнено. Натомість безпека Ethereum забезпечується валідаторами, які роблять стейкінг ETH. Ви можете почати робити ставку ETH вже сьогодні. Дізнайтеся більше про The Merge, доказ частки та стейкінг. Ця сторінка лише для історичного інтересу. + + + + +## Передумови {#prerequisites} + +Щоб краще зрозуміти цю сторінку, радимо спочатку ознайомитися з [транзакціями](/developers/docs/transactions/), [блоками](/developers/docs/blocks/) та [підтвердженням роботи](/developers/docs/consensus-mechanisms/pow/). + +## Що являє собою видобуток Ethereum? Що таке майнінг Ethereum? {#what-is-ethereum-mining} + +Майнінг — це процес створення блоку транзакцій для додавання до блокчейну Ethereum у застарілій архітектурі Ethereum, що базується на підтвердженні роботи. + +Слово «майнінг» походить з аналогії із золотом для криптовалют. Золото або дорогоцінні метали є дефіцитними, так само як і цифрові токени, і єдиний спосіб збільшити загальний обсяг у системі підтвердження роботи — це майнінг. У системі Ethereum на основі підтвердження роботи єдиним способом емісії був майнінг. Однак, на відміну від золота чи дорогоцінних металів, майнінг Ethereum був також способом захисту мережі шляхом створення, перевірки, публікації та поширення блоків у блокчейні. + +Майнінг ефіру = захист мережі + +Майнінг є життєвою силою будь-якого блокчейну на основі підтвердження роботи. Майнери Ethereum (комп'ютери, на яких запущено програмне забезпечення) використовували свій час та обчислювальну потужність для обробки транзакцій та створення блоків до переходу на доказ частки. + +## Навіщо потрібні майнери? {#why-do-miners-exist} + +У децентралізованих системах, як-от Ethereum, необхідно забезпечити, щоб усі погоджувалися з порядком транзакцій. Майнери сприяли цьому, вирішуючи складні обчислювальні завдання для створення блоків, захищаючи мережу від атак. + +[Докладніше про підтвердження роботи](/developers/docs/consensus-mechanisms/pow/) + +Раніше будь-хто міг майнити в мережі Ethereum за допомогою свого комп'ютера. Однак не кожен міг вигідно майнити ефір (ETH). У більшості випадків майнерам доводилося купувати спеціалізоване комп'ютерне обладнання та мати доступ до недорогих джерел енергії. Звичайний комп’ютер навряд чи заробив би достатньо винагород за блоки, щоб покрити пов’язані з майнінгом витрати. + +### Вартість майнінгу {#cost-of-mining} + +- Потенційні витрати на обладнання, необхідні для створення та обслуговування майнінгової установки +- Вартість електроенергії для живлення майнінгової установки +- Якщо ви займалися майнінгом у пулі, ці пули зазвичай стягували фіксовану відсоткову комісію за кожен блок, згенерований пулом. +- Потенційна вартість обладнання для підтримки майнінгової установки (вентиляція, моніторинг енергії, електропроводка тощо) + +Щоб детальніше вивчити прибутковість майнінгу, скористайтеся калькулятором майнінгу, наприклад, тим, що надає [Etherscan](https://etherscan.io/ether-mining-calculator). + +## Як відбувався майнінг транзакцій в Ethereum {#how-ethereum-transactions-were-mined} + +Нижче наведено огляд того, як відбувався майнінг транзакцій у системі Ethereum на основі підтвердження роботи. Аналогічний опис цього процесу для Ethereum на основі доказу частки можна знайти [тут](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). + +1. Користувач створює та підписує запит на [транзакцію](/developers/docs/transactions/) за допомогою приватного ключа певного [облікового запису](/developers/docs/accounts/). +2. Користувач транслює запит на транзакцію в усій мережі Ethereum з певного [вузла](/developers/docs/nodes-and-clients/). +3. Після того, як будуть отримані нові запити на транзакції, кожен вузол мережі Ethereum додасть запит у свій локальний mempool, що є списком всіх запитів на транзакції, які ще не були зафіксовані в даних блоку. +4. У певний момент майнінговий вузол об'єднує кілька десятків або сотень запитів на транзакції в потенційний [блок](/developers/docs/blocks/) таким чином, щоб максимізувати [комісії за транзакції](/developers/docs/gas/), які він заробляє, залишаючись при цьому в межах ліміту газу для блоку. Таким чином, вузол видобування: + 1. Перевіряє дійсність кожного запиту на транзакцію (тобто ніхто не намагається переказати ефір з облікового запису, для якого не створено підпис, запит не є спотвореним тощо), а потім виконує код запиту, змінюючи стан своєї локальної копії EVM. The miner awards the transaction fee for each such transaction request to their own account. + 2. Починає процес створення «сертифіката легітимності» з підтвердженням роботи для потенційного блоку, після того як усі запити на транзакції в блоці будуть перевірені та виконані на локальній копії EVM. +5. Eventually, a miner will finish producing a certificate for a block which includes our specific transaction request. The miner then broadcasts the completed block, which includes the certificate and a checksum of the claimed new EVM state. +6. Other nodes hear about the new block. They verify the certificate, execute all transactions on the block themselves (including the transaction originally broadcasted by our user), and verify that the checksum of their new EVM state after the execution of all transactions matches the checksum of the state claimed by the"miner’s"block. Only then do these nodes append this block to the tail of their blockchain, and accept the new EVM state as the canonical state. +7. Each node removes all transactions in the new block from their local mempool of unfulfilled transaction requests. +8. New nodes joining the network download all blocks in sequence, including the block containing our transaction of interest. They initialize a local EVM copy (which starts as a blank-state EVM), and then go through the process of executing every transaction in every block on top of their local EVM copy, verifying state checksums at each block along the way. + +Every transaction is mined (included in a new block and propagated for the first time) once, but executed and verified by every participant in the process of advancing the canonical EVM state. Це підкреслює одну з центральних мантр блокчейну: **не довіряй, а перевіряй**. + +## Блоки оммер (uncle) {#ommer-blocks} + +Майнінг блоків на основі підтвердження роботи був імовірнісним, тобто іноді два дійсні блоки публікувалися одночасно через затримку в мережі. У цьому випадку протокол мав визначити найдовший (і, отже, найбільш "дійсний") ланцюг, забезпечуючи при цьому справедливість щодо майнерів шляхом часткової винагороди за невключений запропонований дійсний блок. Це заохочувало подальшу децентралізацію мережі, оскільки менші майнери, які могли стикатися з більшою затримкою, все одно могли отримувати прибуток через винагороди за [оммер](/glossary/#ommer) блоки. + +Термін " оммер "є нейтральним з гендерної точки зору терміном для брата або сестри батьківського блоку, але його також іноді називають"дядьком". **Після переходу Ethereum на доказ частки оммер-блоки більше не майняться**, оскільки в кожному слоті обирається лише один автор блоку. Ви можете побачити цю зміну, переглянувши [історичний графік](https://ycharts.com/indicators/ethereum_uncle_rate) видобутих оммер-блоків. + +## Наочна демонстрація {#a-visual-demo} + +Watch Austin walk you through mining and the proof-of-work blockchain. + + + +## Алгоритм майнінгу {#mining-algorithm} + +Основна мережа Ethereum (Mainnet) використовувала лише один алгоритм майнінгу — ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash був наступником оригінального алгоритму для досліджень та розробок, відомого як ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). + +[Докладніше про алгоритми майнінгу](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## Пов'язані теми {#related-topics} + +- [Газ](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [Підтвердження роботи](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..271034fe163 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,330 @@ +--- +title: Dagger-Hashimoto +description: "Детальний огляд алгоритму Dagger-Hashimoto." +lang: uk +--- + +Dagger-Hashimoto — це початкова дослідницька реалізація та специфікація для алгоритму майнінгу Ethereum. Алгоритм Dagger-Hashimoto був замінений на [Ethash](#ethash). Майнінг було повністю вимкнено під час [Злиття (The Merge)](/roadmap/merge/) 15 вересня 2022 року. Відтоді безпека Ethereum забезпечується за допомогою механізму [доказу частки володіння (proof-of-stake)](/developers/docs/consensus-mechanisms/pos). Ця сторінка представляє історичний інтерес: інформація на ній більше не є актуальною для Ethereum після Злиття. + +## Передумови {#prerequisites} + +Щоб краще зрозуміти цю сторінку, ми рекомендуємо вам спочатку ознайомитися з [консенсусом доказу виконаної роботи (proof-of-work)](/developers/docs/consensus-mechanisms/pow), [майнінгом](/developers/docs/consensus-mechanisms/pow/mining) та [алгоритмами майнінгу](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto має на меті досягнення двох цілей: + +1. **Стійкість до ASIC**: вигода від створення спеціалізованого обладнання для цього алгоритму має бути якомога меншою +2. **Верифікація легким клієнтом**: блок має ефективно перевірятися легким клієнтом. + +За допомогою додаткової модифікації ми також визначаємо, як за бажанням досягти третьої мети, але за рахунок додаткової складності: + +**Повне зберігання ланцюга**: майнінг повинен вимагати зберігання повного стану блокчейну (через нерегулярну структуру дерева станів Ethereum ми припускаємо, що можливе деяке скорочення, зокрема, деяких часто використовуваних контрактів, але ми хочемо звести це до мінімуму). + +## Генерація DAG {#dag-generation} + +Код для алгоритму буде визначено на Python нижче. По-перше, ми надаємо `encode_int` для маршалінгу беззнакових цілих чисел заданої точності в рядки. Його зворотний порядок також наведено: + +```python +NUM_BITS = 512 + +def encode_int(x): + "Encode an integer x as a string of 64 characters using a big-endian scheme" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "Unencode an integer x from a string using a big-endian scheme" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +Далі ми припускаємо, що `sha3` — це функція, яка приймає ціле число та виводить ціле число, а `dbl_sha3` — це функція подвійного sha3; якщо ви перетворюєте цей еталонний код у реалізацію, використовуйте: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### Параметри {#parameters} + +Для алгоритму використовуються такі параметри: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 + +params = { + "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536 + "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536 + # with epochtime=20000 gives 882 MB growth per year + "cache_size": 2500, # Size of the light client's cache (can be chosen by light + # client; not part of the algo spec) + "diff": 2**14, # Difficulty (adjusted during block evaluation) + "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated) + "k": 1, # Number of parents of a node + "w": w, # Used for modular exponentiation hashing + "accesses": 200, # Number of dataset accesses during hashimoto + "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation +} +``` + +У цьому випадку `P` — це просте число, вибране так, що `log₂(P)` трохи менше 512, що відповідає 512 бітам, які ми використовуємо для представлення наших чисел. Зауважте, що насправді потрібно зберігати лише останню половину DAG, тому фактична потреба в оперативній пам’яті починається з 1 ГБ і зростає на 441 МБ на рік. + +### Побудова графа Dagger {#dagger-graph-building} + +Примітив побудови графа Dagger визначається так: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +По суті, він починає граф як один вузол `sha3(seed)` і звідти починає послідовно додавати інші вузли на основі випадкових попередніх вузлів. Коли створюється новий вузол, обчислюється модульний степінь початкового числа для випадкового вибору деяких індексів, менших за `i` (використовуючи `x % i` вище), і значення вузлів за цими індексами використовуються в обчисленні для генерації нового значення для `x`, яке потім передається в невелику функцію доказу виконаної роботи (на основі XOR), щоб зрештою згенерувати значення графа за індексом `i`. Обґрунтування цього конкретного дизайну полягає в тому, щоб примусити послідовний доступ до DAG; наступне значення DAG, до якого буде отримано доступ, неможливо визначити, доки не буде відомо поточне значення. Нарешті, модульне піднесення до степеня додатково гешує результат. + +Цей алгоритм спирається на кілька результатів з теорії чисел. Дивіться обговорення в додатку нижче. + +## Оцінка легкого клієнта {#light-client-evaluation} + +Наведена вище конструкція графа призначена для того, щоб дозволити реконструювати кожен вузол у графі, обчислюючи піддерево лише з невеликої кількості вузлів і вимагаючи лише невеликого обсягу допоміжної пам’яті. Зауважте, що при k=1 піддерево — це лише ланцюжок значень, що ведуть до першого елемента в DAG. + +Обчислювальна функція легкого клієнта для DAG працює так: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +По суті, це просто переписаний вищезгаданий алгоритм, який видаляє цикл обчислення значень для всього DAG і замінює попередній пошук вузла рекурсивним викликом або пошуком у кеші. Зауважте, що для `k=1` кеш не потрібен, хоча подальша оптимізація фактично попередньо обчислює перші кілька тисяч значень DAG і зберігає їх як статичний кеш для обчислень; дивіться реалізацію коду цього в додатку. + +## Подвійний буфер DAG {#double-buffer} + +У повному клієнті використовується [_подвійний буфер_](https://wikipedia.org/wiki/Multiple_buffering) з 2 DAG, створених за наведеною вище формулою. Ідея полягає в тому, що DAG створюються кожні `epochtime` блоків відповідно до наведених вище параметрів. Замість того, щоб клієнт використовував останній створений DAG, він використовує попередній. Перевага цього полягає в тому, що це дозволяє з часом замінювати DAG без необхідності включати крок, на якому майнери повинні раптово перерахувати всі дані. В іншому випадку існує ймовірність різкого тимчасового уповільнення обробки ланцюга через регулярні проміжки часу та різкого посилення централізації. Таким чином, ризики атаки 51% протягом тих кількох хвилин, перш ніж усі дані будуть перераховані. + +Алгоритм, що використовується для генерації набору DAG, які використовуються для обчислення роботи для блоку, має такий вигляд: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # No back buffer is possible, just make front buffer + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +Ідея оригінального Hashimoto полягає у використанні блокчейну як набору даних, виконуючи обчислення, яке вибирає N індексів з блокчейну, збирає транзакції за цими індексами, виконує операцію XOR над цими даними та повертає геш результату. Оригінальний алгоритм Тадеуша Дрижа, перекладений на Python для узгодженості, має такий вигляд: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +На жаль, хоча Hashimoto вважається стійким до оперативної пам’яті, він покладається на 256-бітну арифметику, що має значні обчислювальні накладні витрати. Однак, щоб вирішити цю проблему, Dagger-Hashimoto використовує лише 64 найменш значущі біти під час індексування свого набору даних. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +Використання подвійного SHA3 дозволяє здійснювати попередню перевірку без даних майже миттєво, перевіряючи лише те, що було надано правильне проміжне значення. Цей зовнішній шар доказу виконаної роботи є дуже дружнім до ASIC і досить слабким, але існує для того, щоб ще більше ускладнити DDoS-атаки, оскільки цю невелику кількість роботи необхідно виконати, щоб створити блок, який не буде негайно відхилено. Ось версія для легкого клієнта: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## Майнінг і перевірка {#mining-and-verifying} + +Тепер давайте об’єднаємо все це в алгоритм майнінгу: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +Ось алгоритм перевірки: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Верифікація, дружня до легких клієнтів: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Крім того, зауважте, що Dagger-Hashimoto накладає додаткові вимоги до заголовка блоку: + +- Щоб дворівнева перевірка працювала, заголовок блоку повинен мати як nonce, так і середнє значення до sha3 +- Десь заголовок блоку повинен зберігати sha3 поточного набору початкових значень + +## Для подальшого читання {#further-reading} + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ + +## Додаток {#appendix} + +Як зазначалося вище, генератор випадкових чисел, що використовується для створення DAG, спирається на деякі результати з теорії чисел. По-перше, ми надаємо гарантію, що генератор випадкових чисел Лемера, що є основою для змінної `picker`, має великий період. По-друге, ми показуємо, що `pow(x,3,P)` не відображатиме `x` на `1` або `P-1` за умови, що `x ∈ [2,P-2]` на початку. Нарешті, ми показуємо, що `pow(x,3,P)` має низький рівень колізій при використанні як геш-функції. + +### Генератор випадкових чисел Лемера {#lehmer-random-number} + +Хоча функція `produce_dag` не потребує створення незміщених випадкових чисел, потенційна загроза полягає в тому, що `seed**i % P` приймає лише кілька значень. Це може надати перевагу майнерам, які розпізнають закономірність, над тими, хто цього не робить. + +Щоб уникнути цього, звертаються до результату з теорії чисел. [_Безпечне просте число_](https://en.wikipedia.org/wiki/Safe_prime) визначається як просте число `P`, таке, що `(P-1)/2` також є простим. _Порядок_ члена `x` [мультиплікативної групи](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` визначається як мінімальне `m` таке, що 
xᵐ mod P ≡ 1
+З огляду на ці визначення, ми маємо: + +> Спостереження 1. Нехай `x` є членом мультиплікативної групи `ℤ/Pℤ` для безпечного простого числа `P`. Якщо `x mod P ≠ 1 mod P` і `x mod P ≠ P-1 mod P`, то порядок `x` дорівнює або `P-1`, або `(P-1)/2`. + +_Доказ_. Оскільки `P` є безпечним простим числом, то за [теоремою Лагранжа][lagrange] ми маємо, що порядок `x` дорівнює `1`, `2`, `(P-1)/2` або `P-1`. + +Порядок `x` не може бути `1`, оскільки за Малою теоремою Ферма ми маємо: + +
xP-1 mod P ≡ 1
+ +Отже, `x` має бути мультиплікативною одиницею `ℤ/nℤ`, яка є унікальною. Оскільки ми припустили, що `x ≠ 1`, це неможливо. + +Порядок `x` не може дорівнювати `2`, якщо `x = P-1`, оскільки це порушило б те, що `P` є простим числом. + +З наведеного вище твердження ми можемо визнати, що ітерація `(picker * init) % P` матиме довжину циклу щонайменше `(P-1)/2`. Це тому, що ми вибрали `P` як безпечне просте число, приблизно рівне вищому степеню двійки, а `init` знаходиться в інтервалі `[2,2**256+1]`. Враховуючи величину `P`, ми ніколи не повинні очікувати циклу від модульного піднесення до степеня. + +Коли ми призначаємо першу комірку в DAG (змінна з позначкою `init`), ми обчислюємо `pow(sha3(seed) + 2, 3, P)`. На перший погляд це не гарантує, що результат не буде ні `1`, ні `P-1`. Однак, оскільки `P-1` є безпечним простим числом, ми маємо таку додаткову гарантію, що є наслідком Спостереження 1: + +> Спостереження 2. Нехай `x` є членом мультиплікативної групи `ℤ/Pℤ` для безпечного простого числа `P`, і нехай `w` є натуральним числом. Якщо `x mod P ≠ 1 mod P` і `x mod P ≠ P-1 mod P`, а також `w mod P ≠ P-1 mod P` і `w mod P ≠ 0 mod P`, тоді `xʷ mod P ≠ 1 mod P` і `xʷ mod P ≠ P-1 mod P` + +### Модульне піднесення до степеня як геш-функція {#modular-exponentiation} + +Для певних значень `P` і `w` функція `pow(x, w, P)` може мати багато колізій. Наприклад, `pow(x,9,19)` приймає лише значення `{1,18}`. + +З огляду на те, що `P` є простим числом, тоді відповідне `w` для функції гешування з модульним піднесенням до степеня можна вибрати, використовуючи такий результат: + +> Спостереження 3. Нехай `P` є простим числом; `w` і `P-1` є взаємно простими тоді й лише тоді, коли для всіх `a` та `b` у `ℤ/Pℤ`:
`aʷ mod P ≡ bʷ mod P` тоді й лише тоді, коли `a mod P ≡ b mod P`
+ +Таким чином, з огляду на те, що `P` є простим числом, а `w` є взаємно простим із `P-1`, ми маємо, що `|{pow(x, w, P) : x ∈ ℤ}| = P`, що означає, що геш-функція має мінімально можливий рівень колізій. + +У спеціальному випадку, коли `P` є безпечним простим числом, яке ми вибрали, то `P-1` має лише множники 1, 2, `(P-1)/2` і `P-1`. Оскільки `P` > 7, ми знаємо, що 3 є взаємно простим із `P-1`, отже, `w=3` задовольняє наведене вище твердження. + +## Більш ефективний алгоритм оцінки на основі кешу {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..10c298f93bc --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1019 @@ +--- +title: Ethash +description: "Детальний розгляд алгоритму Ethash." +lang: uk +--- + + + + + + Ethash був алгоритмом майнінгу Ethereum на основі підтвердження роботи. Наразі підтвердження роботи **повністю вимкнено**, а Ethereum захищено за допомогою [доказу частки](/developers/docs/consensus-mechanisms/pos/). Дізнайтеся більше про [The Merge](/roadmap/merge/), [доказ частки](/developers/docs/consensus-mechanisms/pos/) та [стейкінг](/staking/). Ця сторінка лише для історичного інтересу! + + + + +Ethash — це модифікована версія алгоритму [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Підтвердження роботи Ethash є [вимогливим до пам’яті](https://wikipedia.org/wiki/Memory-hard_function), що, як вважалося, робить алгоритм стійким до ASIC. Зрештою були розроблені ASIC для Ethash, але майнінг на графічних процесорах (GPU) залишався життєздатним варіантом, доки не було вимкнено підтвердження роботи. Ethash все ще використовується для майнінгу інших монет в інших мережах із підтвердженням роботи, не пов’язаних з Ethereum. + +## Як працює Ethash? {#how-does-ethash-work} + +Потужність пам'яті досягається за допомогою алгоритму підтвердження роботи, який вимагає вибору підмножин фіксованого ресурсу залежно від одноразового заголовка і блоку. Цей ресурс (розміром у кілька гігабайт) називається DAG. DAG змінюється кожні 30 000 блоків — вікно тривалістю ~125 годин, яке називається епохою (приблизно 5,2 дня), і генерується протягом певного часу. Оскільки DAG залежить лише від висоти блоку, його можна попередньо згенерувати, але якщо ні, клієнту потрібно дочекатися завершення цього процесу, щоб створити блок. Якщо клієнти не генерують і не кешують DAG заздалегідь, мережа може відчувати велику затримку блоку під час кожної зміни епохи. Зауважте, що DAG не потрібно створювати для перевірки підтвердження роботи, що, по суті, дозволяє проводити перевірку як із низьким рівнем ЦП, так і з невеликою пам’яттю. + +Загальний маршрут, який використовує алгоритм, такий: + +1. Існує **початкове значення**, яке можна обчислити для кожного блоку шляхом сканування заголовків блоків до цього моменту. +2. З початкового значення можна обчислити **псевдовипадковий кеш розміром 16 МБ**. Легкі клієнти зберігають кеш. +3. З кешу ми можемо згенерувати **набір даних розміром 1 ГБ** з тією властивістю, що кожен елемент у наборі даних залежить лише від невеликої кількості елементів із кешу. Повні клієнти та майнери зберігають набір даних. Набір даних лінійно зростає з часом. +4. Майнінг включає захоплення випадкових фрагментів набору даних і їх хешування разом. Перевірку можна виконати при малому обсязі пам’яті, використовуючи кеш для регенерації певних частин набору даних, які вам потрібні, тому вам потрібно лише зберігати кеш. + +Великий набір даних оновлюється раз на кожні 30 000 блоків, тому переважна більшість зусиль майнера буде направлена на зчитування набору даних, а не на внесення в нього зміни. + +## Визначення {#definitions} + +Ми використовуємо такі визначення: + +``` +WORD_BYTES = 4 # bytes in word +DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis +DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch +CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis +CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch +CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache +EPOCH_LENGTH = 30000 # blocks per epoch +MIX_BYTES = 128 # width of mix +HASH_BYTES = 64 # hash length in bytes +DATASET_PARENTS = 256 # number of parents of each dataset element +CACHE_ROUNDS = 3 # number of rounds in cache production +ACCESSES = 64 # number of accesses in hashimoto loop +``` + +### Використання SHA3 {#sha3} + +Розробка Ethereum збіглася в часі з розробкою стандарту SHA3, і в процесі стандартизації було внесено пізню зміну в доповнення фіналізованого хеш-алгоритму, тому хеші Ethereum "sha3_256" і "sha3_512" не є стандартними хешами sha3, а варіантом, який в інших контекстах часто називають "Keccak-256" і "Keccak-512". Див. обговорення, напр., [тут](https://eips.ethereum.org/EIPS/eip-1803), [тут](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) або [тут](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +Будь ласка, майте це на увазі, оскільки хеші "sha3" згадуються в описі алгоритму нижче. + +## Параметри {#parameters} + +Параметри кешу та набору даних Ethash залежать від номера блоку. Розмір кешу та розмір набору даних зростають лінійно; однак ми завжди беремо найбільше просте число, що є меншим за лінійно зростаючий поріг, щоб зменшити ризик випадкових закономірностей, що призводять до циклічної поведінки. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +Таблиці значень розміру набору даних і розміру кешу наведено в додатку. + +## Генерація кешу {#cache-generation} + +Тепер ми визначимо функцію для створення кешу: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # Sequentially produce the initial dataset + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # Use a low-round version of randmemohash + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +Процес створення кешу передбачає спочатку послідовне заповнення 32 МБ пам’яті, а потім виконання двох проходів алгоритму _RandMemoHash_ Серхіо Деміана Лернера з [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Результатом є набір з 524 288 64-байтних значень. + +## Функція агрегації даних {#date-aggregation-function} + +У деяких випадках ми використовуємо алгоритм, натхненний [FNV-хешем](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function), як неасоціативний замінник XOR. Зауважте, що ми множимо просте число на повне 32-бітне вхідне значення, на відміну від специфікації FNV-1, яка по черзі множить просте число на один байт (октет). + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +Зверніть увагу, що, хоча в Жовтій книзі fnv вказано як v1\*(FNV_PRIME ^ v2), усі поточні реалізації послідовно використовують наведене вище визначення. + +## Розрахунок повного набору даних {#full-dataset-calculation} + +Кожен 64-байтний елемент у повному наборі даних об'ємом 1 ГБ обчислюється таким чином: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # initialize the mix + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # fnv it with a lot of random cache nodes based on i + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +По суті, ми об'єднуємо дані з 256 псевдовипадково вибраних вузлів кешу та хешуємо їх, щоб обчислити вузол набору даних. Потім увесь набір даних генерується за допомогою: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## Основний цикл {#main-loop} + +Тепер ми визначимо основний цикл, подібний до "hashimoto", у якому ми агрегуємо дані з повного набору даних, щоб отримати наше кінцеве значення для певного заголовка та nonce. У наведеному нижче коді `header` представляє _хеш_ SHA3-256 RLP-представлення _скороченого_ заголовка блоку, тобто заголовка, що не містить полів **mixHash** і **nonce**. `nonce` — це вісім байтів 64-бітного беззнакового цілого числа в порядку від старшого до молодшого. Отже, `nonce[::-1]` — це восьмибайтове представлення цього значення в порядку від молодшого до старшого: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # combine header+nonce into a 64 byte seed + s = sha3_512(header + nonce[::-1]) + # start the mix with replicated s + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # mix in random dataset nodes + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # compress mix + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +По суті, ми підтримуємо "суміш" шириною 128 байтів і багаторазово послідовно вибираємо 128 байтів із повного набору даних та використовуємо функцію `fnv` для їхнього об'єднання із сумішшю. Використовується 128 байтів послідовного доступу, щоб кожен раунд алгоритму завжди отримував повну сторінку з ОЗП, мінімізуючи промахи буфера асоціативної трансляції, яких теоретично могли б уникнути ASIC. + +Якщо результат цього алгоритму нижчий за бажану ціль, то nonce є дійсним. Зауважте, що додаткове застосування `sha3_256` наприкінці гарантує, що існує проміжний nonce, який може бути наданий для доказу того, що було виконано принаймні невеликий обсяг роботи; ця швидка зовнішня PoW-перевірка може використовуватися для цілей захисту від DDoS. Це також служить для надання статистичної гарантії того, що результат є незміщеним 256-бітним числом. + +## Майнінг {#mining} + +Алгоритм майнінгу визначається таким чином: + +```python +def mine(full_size, dataset, header, difficulty): + # zero-pad target to compare with hash on the same digit + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## Визначення хешу початкового значення {#seed-hash} + +Щоб обчислити хеш початкового значення, який буде використовуватися для майнінгу поверх заданого блоку, ми використовуємо такий алгоритм: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +Зауважте, що для безперебійного майнінгу та перевірки ми рекомендуємо попередньо обчислювати майбутні хеші початкових значень і набори даних в окремому потоці. + +## Для подальшого читання {#further-reading} + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ + +## Додаток {#appendix} + +Наведений нижче код слід додати на початку, якщо ви зацікавлені в запуску наведеної вище специфікації python як коду. + +```python +import sha3, copy + +# Assumes little endian bit ordering (same as Intel architectures) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# sha3 hash function, outputs 64 bytes +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### Розміри даних {#data-sizes} + +Наведені нижче таблиці пошуку містять приблизно 2048 табульованих епох розмірів даних і розмірів кешу. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..5bb24fd3ce5 --- /dev/null +++ b/public/content/translations/uk/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "Алгоритми майнінгу" +description: "Детальний огляд алгоритмів, які використовуються для майнінгу Ethereum." +lang: uk +--- + + + + + +Підтвердження роботи більше не лежить в основі механізму консенсусу Ethereum, що означає, що майнінг було вимкнено. Натомість безпека Ethereum забезпечується валідаторами, які роблять стейкінг ETH. Ви можете почати робити ставку ETH вже сьогодні. Дізнайтеся більше про The Merge, доказ частки та стейкінг. Ця сторінка лише для історичного інтересу. + + + + +Майнінг Ethereum використовував алгоритм, відомий як Ethash. Фундаментальна ідея алгоритму полягає в тому, що майнер намагається знайти число, використовуючи обчислення грубої сили, щоб кінцевий хеш був меншим за порогове значення, визначене обчисленою складністю. Цей рівень складності можна динамічно регулювати, дозволяючи створювати блоки через регулярні проміжки часу. + +## Передумови {#prerequisites} + +Щоб краще зрозуміти цю сторінку, ми радимо вам спочатку ознайомитися з [консенсусом підтвердження роботи](/developers/docs/consensus-mechanisms/pow) та [майнінгом](/developers/docs/consensus-mechanisms/pow/mining). + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto був попереднім дослідницьким алгоритмом для майнінгу Ethereum, який замінено на Ethash. Це було об'єднання двох різних алгоритмів: Dagger і Hashimoto. Це була лише дослідницька реалізація, і її замінив Ethash до моменту запуску основної мережі Ethereum. + +[Dagger](http://www.hashcash.org/papers/dagger.html) передбачає створення [спрямованого ациклічного графа](https://en.wikipedia.org/wiki/Directed_acyclic_graph), випадкові фрагменти якого хешуються разом. Основний принцип полягає в тому, що кожен одноразовий код вимагає лише невеликої частини великого загального дерева даних. Повторне обчислення піддерева для кожного одноразового коду є непосильним для майнінгу – отже, потрібно зберігати дерево, – але це нормально для перевірки вартості одного одноразового номера. Dagger був розроблений як альтернатива існуючим алгоритмам, таким як Scrypt, які важко піддаються збереженню, але їх важко перевірити, коли їхня складність зростає до дійсно безпечного рівня. Однак Dagger був вразливий до апаратного забезпечення спільної пам’яті і відмовився від інших напрямків досліджень. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) — це алгоритм, який додає стійкість до ASIC, оскільки він обмежений операціями вводу-виводу (тобто зчитування з пам'яті є обмежувальним фактором у процесі майнінгу). Теорія полягає в тому, що оперативна пам’ять є більш доступною, ніж обчислення; Дослідження на мільярди доларів уже досліджували оптимізацію оперативної пам’яті для різних випадків використання, які часто включають шаблони майже випадкового доступу (звідси «пам’ять із довільним доступом»). В результаті існуюча оперативна пам’ять, ймовірно, буде досить близькою до оптимальної для оцінки алгоритму. Hashimoto використовує блокчейн як джерело даних, одночасно задовольняючи (1) і (3) вище. + +Dagger-Hashimoto використовував виправлені версії алгоритмів Dagger і Hashimoto. Різниця між Dagger Hashimoto і Hashimoto полягає в тому, що замість того, щоб використовувати блокчейн як джерело даних, Dagger Hashimoto використовує спеціально згенерований набір даних, який оновлюється на основі даних блоку кожні N блоків. Набір даних генерується за допомогою алгоритму Dagger, що дозволяє ефективно обчислювати підмножину, специфічну для кожного одноразового коду для легкого алгоритму перевірки клієнта. Різниця між Dagger Hashimoto та Dagger полягає в тому, що, на відміну від оригінального Dagger, набір даних, що використовується для запиту до блока, є напівпостійним і оновлюється лише періодично (наприклад, раз на тиждень). Це означає, що частка зусиль для створення набору даних близька до нуля, тому аргументи Серджіо Лернера щодо прискорення спільної пам’яті стають незначними. + +Докладніше про [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). + +## Ethash {#ethash} + +Ethash був алгоритмом майнінгу, який фактично використовувався в реальній мережі Ethereum за архітектурою proof-of-work, яка тепер не підтримується. Ethash став фактично новою назвою, даною конкретній версії Dagger-Hashimoto після того, як алгоритм був значно оновлений, водночас успадкувавши фундаментальні принципи свого попередника. У мережі Ethereum Mainnet використовувався лише Ethash, а Dagger Hashimoto був дослідницькою версією алгоритму майнінгу, яку замінили ще до початку майнінгу в Ethereum Mainnet. + +[Докладніше про Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## Для подальшого читання {#further-reading} + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ diff --git a/public/content/translations/uk/developers/docs/dapps/index.md b/public/content/translations/uk/developers/docs/dapps/index.md new file mode 100644 index 00000000000..de21ae43cbd --- /dev/null +++ b/public/content/translations/uk/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "Технічний вступ до dapps" +description: +lang: uk +--- + +Децентралізований застосунок (dapp) — це застосунок, створений у децентралізованій мережі, що поєднує [смарт-контракт](/developers/docs/smart-contracts/) і зовнішній інтерфейс користувача. Зауважте, що в Ethereum розумні контракти доступні та прозорі - як відкриті API - тож ваш додаток може навіть включати розумний контракт, написаний кимось іншим. + +## Передумови {#prerequisites} + +Перш ніж вивчати dapps, вам слід ознайомитися з [основами блокчейну](/developers/docs/intro-to-ethereum/), а також прочитати про мережу Ethereum і те, як вона децентралізована. + +## Визначення dapp {#definition-of-a-dapp} + +Інтернет-код dapp працює у децентралізованій мережі однорангової мережі. Порівняйте це з додатком, де бекенд-код працює на централізованих серверах. + +Dapp може мати код інтерфейсу та користувацькі інтерфейси, написані будь-якою мовою (так само, як програма), які можуть здійснювати виклики до свого бекенда. Крім того, його зовнішній інтерфейс можна розмістити в децентралізованому сховищі, наприклад [IPFS](https://ipfs.io/). + +- **Децентралізованість** — dapps працюють на Ethereum, відкритій публічній децентралізованій платформі, де жодна людина чи група не має контролю. +- **Детермінованість** — dapps виконують ту саму функцію незалежно від середовища, у якому вони виконуються. +- **Повнота за Тьюрінгом** — dapps можуть виконувати будь-які дії за наявності необхідних ресурсів. +- **Ізольованість** — dapps виконуються у віртуальному середовищі, відомому як віртуальна машина Ethereum, тож якщо у смарт-контракті є помилка, це не перешкоджатиме нормальному функціонуванню мережі блокчейну. + +### Про смарт-контракти {#on-smart-contracts} + +Щоб представити dapps, нам потрібно запровадити розумні контракти – бекенд для dapp через відсутність кращого терміну. Щоб отримати детальний огляд, перейдіть до нашого розділу про [смарт-контракти](/developers/docs/smart-contracts/). + +Розумний контракт - це код, який живе на блокчейні Ethereum і працює точно так, як запрограмований. Після того як розумні контракти будуть розгорнуті на сайті, ви зможете їх редагувати. Dapps можуть бути децентралізовані, оскільки вони контролюються логікою, записаною в контракті, а не окремою особою чи компанією. Це також означає, що вам потрібно дуже ретельно розробляти свої контракти та ретельно їх тестувати. + +## Переваги розробки dapp {#benefits-of-dapp-development} + +- **Відсутність простоїв** – щойно смарт-контракт розгортається в блокчейні, мережа загалом завжди зможе обслуговувати клієнтів, які бажають взаємодіяти з контрактом. Таким чином, зловмисники не можуть запускати атаки відмови в обслуговуванні, спрямовані на окремі програми. +- **Конфіденційність** – вам не потрібно надавати свою справжню особу, щоб розгорнути dapp або взаємодіяти з ним. +- **Стійкість до цензури** – жодна окрема сутність у мережі не може заблокувати користувачам можливість надсилати транзакції, розгортати dapps або зчитувати дані з блокчейну. +- **Повна цілісність даних** – дані, що зберігаються в блокчейні, є незмінними й незаперечними завдяки криптографічним примітивам. Зловмисники не можуть підробити транзакції або інші дані, які вже були оприлюднені. +- **Бездовірні обчислення/поведінка, що перевіряється** – смарт-контракти можна проаналізувати, і вони гарантовано виконуватимуться передбачуваним чином без необхідності довіряти центральному органу. Це не правильно у традиційних моделях; наприклад, коли ми використовуємо банківські онлайн-системи, ми повинні вірити, що фінансові установи не зловживатимуть нашими фінансовими даними, не підроблятимуть записи та не зможуть зламати. + +## Недоліки розробки dapp {#drawbacks-of-dapp-development} + +- **Обслуговування** – Dapps може бути складніше обслуговувати, оскільки код і дані, опубліковані в блокчейні, важче змінити. Розробникам важко оновлювати свої децентралізовані програми (або базові дані, що зберігаються в них) після їх розгортання, навіть якщо в старій версії виявлено помилки або загрози безпеці. +- **Втрати продуктивності** – існують значні втрати продуктивності, а масштабування є дуже складним. Щоб досягти рівня безпеки, цілісності, прозорості та надійності, до якого прагне Ethereum, кожен вузол запускає та зберігає кожну транзакцію. Крім того, консенсус доказу частки також потребує часу. +- **Перевантаження мережі** – коли один dapp використовує занадто багато обчислювальних ресурсів, уся мережа перевантажується. Наразі мережа здатна обробляти лише близько 10 транзакцій в секунду; якщо транзакції надсилаються швидше, кількість непідтверджених транзакцій може швидко збільшитися. +- **Досвід користувача** – може бути складніше розробити зручні для користувача рішення, оскільки пересічному кінцевому користувачеві може здатися занадто важким налаштування набору інструментів, необхідного для справді безпечної взаємодії з блокчейном. +- **Централізація** – зручні для користувачів і розробників рішення, створені на базовому рівні Ethereum, у підсумку можуть виглядати як централізовані сервіси. Наприклад, такі служби можуть зберігати ключі або іншу конфіденційну інформацію на сервері, обслуговувати інтернет-сервер за допомогою централізованого сервера або запускати важливу бізнес-логіку на централізованому сервері перед записом у блокчейн. Централізація усуває багато (якщо не всі) переваги блокчейну над традиційною моделлю. + +## Цікавить наочний матеріал? Для тих, хто навчається візуально {#visual-learner} + + + +## Інструменти для створення dapps {#dapp-tools} + +**Scaffold-ETH _- швидко експериментуйте з Solidity, використовуючи зовнішній інтерфейс, що адаптується до вашого смарт-контракту._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [Приклад dapp](https://punkwallet.io/) + +**Create Eth App _- створюйте застосунки на базі Ethereum за допомогою однієї команди._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- інструмент FOSS для створення зовнішніх інтерфейсів dapp з [ABI](/glossary/#abi)._** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- інструмент FOSS для розробників Ethereum, що дозволяє тестувати їхні вузли, а також створювати й налагоджувати виклики RPC з браузера._** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- SDK для всіх мов, смарт-контракти, інструменти та інфраструктура для розробки web3._** + +- [Домашня сторінка](https://thirdweb.com/) +- [Документація](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- платформа для розробки web3 корпоративного рівня, що дозволяє розгортати смарт-контракти, вмикати платежі кредитними картками та міжланцюгові платежі, а також використовувати API для створення, розповсюдження, продажу, зберігання та редагування NFT._** + +- [crossmint.com](https://www.crossmint.com) +- [Документація](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## Для подальшого читання {#further-reading} + +- [Ознайомтеся з dapps](/apps) +- [Архітектура застосунку Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ +- [Посібник із децентралізованих застосунків 2021 року](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [Що таке децентралізовані застосунки?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [Популярні dapps](https://www.alchemy.com/dapps) - _Alchemy_ + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ + +## Пов'язані теми {#related-topics} + +- [Вступ до стека Ethereum](/developers/docs/ethereum-stack/) +- [Фреймворки для розробки](/developers/docs/frameworks/) diff --git a/public/content/translations/uk/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/uk/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..455c54f1f80 --- /dev/null +++ b/public/content/translations/uk/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "Дослідники блоків" +description: "Вступ до блокування дослідників, порталу в світ блокчейн, де можна запитувати інформацію про транзакції, рахунки, контракти та багато іншого." +lang: uk +sidebarDepth: 3 +--- + +Дослідники блоків - це ваш портал до даних Ethereum. Ви можете використовувати їх для перегляду даних про блоки, транзакції, валідаторів, облікові записи та інші дії в мережі в режимі реального часу. + +## Передумови {#prerequisites} + +Ви повинні розуміти основні концепції Ethereum, щоб розбиратися в даних, які надають Вам дослідники блоків. Почніть зі [вступу до Ethereum](/developers/docs/intro-to-ethereum/). + +## Сервіси {#services} + +- [Etherscan](https://etherscan.io/) -_також доступний китайською, корейською, російською та японською мовами_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_також доступний іспанською, французькою, італійською, нідерландською, португальською, російською, китайською та фарсі_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [Оглядач блоків DexGuru](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_також доступний китайською, іспанською, французькою, турецькою, російською, корейською та в'єтнамською мовами_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## Інструменти з відкритим кодом {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## Дані {#data} + +Ethereum - прозорий дизайном, тому все можна перевірити. Дослідники блоків надають інтерфейс для отримання цієї інформації. І це стосується як основної мережі Ethereum, так і тестових мереж, якщо вам знадобляться ці дані. Дані поділяються на дані виконання та дані консенсусу. Дані виконання стосуються транзакцій, які були виконані в певному блоці. Дані консенсусу стосуються самих блоків і валідаторів, які їх запропонували. + +Ось короткий опис типів даних, які ви можете отримати з Дослідників блоків. + +### Дані виконання {#execution-data} + +Нові блоки додаються в Ethereum кожні 12 секунд (якщо тільки автор блоку не пропускає свою чергу), тому в оглядачі блоків додається майже постійний потік даних. Blocks contain a lot of important data that you may find useful: + +**Standard data** + +- Висота блоку – номер блоку та довжина блокчейну (в блоках) на момент створення поточного блоку +- Часова мітка – час, коли блок було запропоновано +- Транзакції – кількість транзакцій, включених у блок +- Одержувач комісії – адреса, яка отримала винагороду за газ від транзакцій +- Нагорода за блок – сума ETH, присуджена валідатору, який запропонував блок +- Розмір – розмір даних у блоці (вимірюється в байтах) +- Використаний газ – загальна кількість одиниць газу, використана транзакціями в блоці +- Ліміт газу – загальні ліміти газу, встановлені транзакціями в блоці +- Базова плата за газ – мінімальний мультиплікатор, необхідний для включення транзакції в блок +- Спалені комісії – скільки ETH спалюється в блоці +- Додаткові дані – будь-які додаткові дані, які конструктор включив у блок + +**Розширена плитка даних мобільного інтернету** + +- Хеш – криптографічний хеш, що представляє заголовок блоку (унікальний ідентифікатор блоку) +- Батьківський хеш – хеш блоку, який був перед поточним блоком +- StateRoot – кореневий хеш дерева Меркла (Merkle trie), у якому зберігається весь стан системи + +### Газ {#gas} + +Не тільки будуть блокувати дослідників надавати вам дані про використання Gas у транзакціях та блоках, але деякі нададуть вам інформацію про поточні ціни на газ в мережі мережі. Це допоможе вам зрозуміти використання мережі, подавати безпечні транзакції та не перевитрачати на газ. Пошукайте API-інтерфейси, які можуть допомогти вам отримати цю інформацію в інтерфейсі вашого товару. Gas-specific data covers: + +- Орієнтовні одиниці газу, необхідні для безпечної, але повільної транзакції (+ орієнтованої ціни та тривалість) +- Орієнтовні підрозділи газу, необхідні для середньої транзакції (+приблизно ціни та тривалість) +- Орієнтовні одиниці газу, необхідні для безпечної, але повільної транзакції (+ орієнтованої ціни та тривалість) +- Середній час підтвердження заснований на ціні газу +- Контракти, які споживають газ, – іншими словами, популярні продукти, які широко використовуються в мережі +- Облікові записи, які витрачають газ, – іншими словами, часті користувачі мережі + +### Транзакції {#transactions} + +Дослідники блоків стали звичайним місцем для людейм, щоб відстежувати хід своїх транзакцій. Це тому, що рівень деталізації, який ви можете отримати, забезпечує додаткову впевненість. Дані транзакції містять в собі: + +**Standard data** + +- Хеш транзакції – хеш, який генерується під час надсилання транзакції +- Статус – індикація того, чи є транзакція очікуваною, невдалою чи успішною +- Блок – блок, у який включено транзакцію +- Часова мітка – час включення транзакції до блоку, запропонованого валідатором +- Від – адреса облікового запису, який надіслав транзакцію +- Кому – адреса одержувача або смарт-контракту, з яким взаємодіє транзакція +- Переказані токени – список токенів, які були переказані в рамках транзакції +- Сума – загальна сума ETH, що переказується +- Комісія за транзакцію – сума, сплачена валідатору за обробку транзакції (розраховується як ціна газу \* використаний газ) + +**Розширена плитка даних мобільного інтернету** + +- Ліміт газу – максимальна кількість одиниць газу, яку може спожити ця транзакція +- Використаний газ – фактична кількість одиниць газу, яку спожила транзакція +- Ціна газу – ціна, встановлена за одиницю газу +- Nonce – номер транзакції для адреси `from` (майте на увазі, що він починається з 0, тому nonce `100` насправді буде 101-ю транзакцією, надісланою цим обліковим записом) +- Вхідні дані – будь-яка додаткова інформація, необхідна для транзакції + +### Облікові записи {#accounts} + +Існує безліч даних про обліковий запис, до яких ви можете отримати доступ. Ось чому часто рекомендується використовувати кілька облікових записів, щоб ваші активи і вартість було нелегко відстежити. Також розробляються деякі рішення, що дозволяють зробити транзакції та операції з рахунками більш конфіденційними. Але ось дані, доступні для облікових записів: + +**User accounts** + +- Адреса облікового запису – публічна адреса, на яку можна надсилати кошти +- Баланс ETH – кількість ETH, пов’язана з цим обліковим записом +- Загальна вартість ETH – вартість ETH +- Токени – токени, пов’язані з обліковим записом, та їхня вартість +- Історія транзакцій – список усіх транзакцій, де цей обліковий запис був відправником або одержувачем + +**Розумні контракти** + +Облікові записи смартконтрактів містять всі дані, які матимуть облікові записи користувачів, але деякі дослідники блоків також зображають деяку інформацію про код. Приклади містять в собі: + +- Автор контракту – адреса, яка розгорнула контракт у Mainnet +- Транзакція створення – транзакція, що включала розгортання в Mainnet +- Вихідний код – код смарт-контракту на Solidity або Vyper +- ABI контракту – бінарний інтерфейс програми контракту: виклики, які робить контракт, і отримані дані +- Код створення контракту – скомпільований байт-код смарт-контракту, створений під час компіляції смарт-контракту, написаного на Solidity, Vyper тощо. +- Події контракту – історія методів, викликаних у смарт-контракті, – по суті, спосіб побачити, як і як часто використовується контракт + +### Токени {#tokens} + +Токени є типом контракту, тому у них будуть схожі дані для розумного контракту. Але оскільки вони мають цінність і можуть торгувати, у них є додаткові бали на даних: + +- Тип – чи є вони ERC-20, ERC-721 або іншим стандартом токенів +- Ціна – якщо це токени ERC-20, вони матимуть поточну ринкову вартість +- Ринкова капіталізація – якщо це токени ERC-20, вони матимуть ринкову капіталізацію (розраховується як ціна \* загальна пропозиція) +- Загальна пропозиція – кількість токенів в обігу +- Власники – кількість адрес, які володіють токеном +- Перекази – кількість разів, коли токен було переказано між обліковими записами +- Історія транзакцій – історія всіх транзакцій, що включають токен +- Адреса контракту – адреса токена, який був розгорнутий у Mainnet +- Десяткові знаки – токени ERC-20 є подільними та мають десяткові знаки + +### Мережа {#network} + +Деякі дані блоків стосуються здоров'я Ethereum у більш цілісному аспекті. + +- Загальна кількість транзакцій – кількість транзакцій з моменту створення Ethereum +- Транзакцій за секунду – кількість транзакцій, які можна обробити за секунду +- Ціна ETH – поточна вартість 1 ETH +- Загальна пропозиція ETH – кількість ETH в обігу; пам’ятайте, що нові ETH створюються зі створенням кожного блоку у вигляді винагород за блок +- Ринкова капіталізація – розрахунок ціни \* пропозиції + +## Дані рівня консенсусу {#consensus-layer-data} + +### Епоха {#epoch} + +З міркувань безпеки в кінці кожної епохи (кожні 6,4 хвилини) створюються рандомізовані комітети валідаторів. Epoch data includes: + +- Epoch number +- Статус фіналізації – чи була епоха фіналізована (так/ні) +- Час – час закінчення епохи +- Атестації – кількість атестацій в епосі (голоси за блоки в слотах) +- Депозити – кількість депозитів ETH, включених в епоху (валідатори повинні внести ETH у стейкінг, щоб стати валідаторами) +- Слешинги – кількість штрафів, накладених на авторів блоків або атестаторів +- Участь у голосуванні – кількість застейканих ETH, використаних для атестації блоків +- Валідатори – кількість валідаторів, активних протягом епохи +- Середній баланс валідатора – середній баланс для активних валідаторів +- Слоти – кількість слотів, включених в епоху (слоти містять один дійсний блок) + +### Слот {#slot} + +Slots are opportunities for block creation, the data available for each slot includes: + +- Епоха – епоха, у якій слот є дійсним +- Slot number +- Статус – статус слоту (запропоновано/пропущено) +- Час – часова мітка слоту +- Автор – валідатор, який запропонував блок для слоту +- Корінь блоку – кореневий хеш дерева (hash-tree-root) BeaconBlock +- Батьківський корінь – хеш попереднього блоку +- Корінь стану – кореневий хеш дерева (hash-tree-root) BeaconState +- Signature +- Randao reveal +- Графіті – автор блоку може включити 32-байтове повідомлення до своєї пропозиції блоку +- Дані виконання + - Block hash + - Deposit count + - Deposit root +- Атестації – кількість атестацій для блоку в цьому слоті +- Депозити – кількість депозитів протягом цього слоту +- Добровільні виходи – кількість валідаторів, які вийшли протягом слоту +- Слешинги – кількість штрафів, накладених на авторів блоків або атестаторів +- Голоси – валідатори, які проголосували за блок у цьому слоті + +### Блоки {#blocks-1} + +Proof-of-stake поділяє час на слоти та епохи. So that means new data! + +- Автор – валідатор, який був алгоритмічно обраний для пропозиції нового блоку +- Епоха – епоха, у якій було запропоновано блок +- Слот – слот, у якому було запропоновано блок +- Атестації – кількість атестацій, включених у слот. Атестації схожі на голоси, які вказують на те, що блок готовий до передачі в Beacon Chain. + +### Валідатори {#validators} + +Validators are responsible for proposing blocks and attesting to them within slots. + +- Номер валідатора – унікальний номер, що представляє валідатора +- Поточний баланс – баланс валідатора, включаючи винагороди +- Ефективний баланс – баланс валідатора, який використовується для стейкінгу +- Дохід – винагороди або штрафи, отримані валідатором +- Статус – чи є валідатор зараз онлайн та активним +- Ефективність атестації – середній час, необхідний для включення атестацій валідатора в ланцюжок +- Право на активацію – дата (та епоха), коли валідатор став доступним для валідації +- Активний із – дата (та епоха), коли валідатор став активним +- Запропоновані блоки – блок, який запропонував валідатор +- Атестації – атестації, які надав валідатор +- Депозити – адреса відправника, хеш транзакції, номер блоку, часова мітка, сума та статус депозиту для стейкінгу, зробленого валідатором + +### Атестації {#attestations} + +Attestations are "yes" votes to include blocks in the chain. Their data relates to a record of the attestation and the validators who attested + +- Слот – слот, у якому відбулася атестація +- Індекс комітету – індекс комітету в заданому слоті +- Біти агрегації – представляють агреговану атестацію всіх валідаторів, що беруть участь в атестації +- Валідатори – валідатори, які надали атестації +- Корінь блоку Beacon – вказує на блок, який атестують валідатори +- Джерело – вказує на останню підтверджену епоху +- Ціль – вказує на останню межу епохи +- Signature + +### Мережа {#network-1} + +Дані верхнього рівня шару консенсусу включають наступне: + +- Current epoch +- Current slot +- Активні валідатори – кількість активних валідаторів +- Валідатори в очікуванні – кількість валідаторів, які очікують на активацію +- Застейкані ETH – кількість ETH, застейканих у мережі +- Середній баланс – середній баланс ETH валідаторів + +## Оглядачі блоків {#block-explorers} + +- [Etherscan](https://etherscan.io/) – оглядач блоків, який можна використовувати для отримання даних для основної мережі Ethereum (Mainnet) і тестових мереж (Testnet) +- [3xpl](https://3xpl.com/ethereum) – оглядач Ethereum з відкритим кодом без реклами, що дозволяє завантажувати свої набори даних +- [Beaconcha.in](https://beaconcha.in/) – оглядач блоків із відкритим кодом для основної мережі Ethereum (Mainnet) і тестових мереж (Testnet) +- [Blockchair](https://blockchair.com/ethereum) – найбільш приватний оглядач Ethereum. Also for sorting and filtering (mempool) data +- [Etherchain](https://www.etherchain.org/) – оглядач блоків для основної мережі Ethereum (Mainnet) +- [Ethplorer](https://ethplorer.io/) – оглядач блоків із фокусом на токенах для основної мережі Ethereum (Mainnet) і тестової мережі Kovan + +## Для подальшого читання {#further-reading} + +_Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!_ + +## Пов'язані теми {#related-topics} + +- [Транзакції](/developers/docs/transactions/) +- [Облікові записи](/developers/docs/accounts/) +- [Мережі](/developers/docs/networks/) diff --git a/public/content/translations/uk/developers/docs/data-and-analytics/index.md b/public/content/translations/uk/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..1210864de6f --- /dev/null +++ b/public/content/translations/uk/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "Дані та аналітика" +description: "Як отримувати ончейн-аналітику та дані для використання у ваших dapps" +lang: uk +--- + +## Вступ {#Introduction} + +Оскільки використання мережі продовжує зростати, все більша кількість цінної інформації буде міститися в ончейн-даних. Оскільки обсяг даних стрімко зростає, обчислення та агрегування цієї інформації для звітування або керування dapp може стати трудомістким і тривалим процесом. + +Використання наявних постачальників даних може прискорити розробку, забезпечити точніші результати та зменшити поточні витрати на технічне обслуговування. Це дозволить команді зосередитися на основній функціональності, яку намагається забезпечити їхній проєкт. + +## Передумови {#prerequisites} + +Вам слід зрозуміти основну концепцію [оглядачів блоків](/developers/docs/data-and-analytics/block-explorers/), щоб краще зрозуміти їх використання в контексті аналітики даних. Крім того, ознайомтеся з концепцією [індексу](/glossary/#index), щоб зрозуміти переваги, які він додає до архітектури системи. + +З точки зору основ архітектури, необхідно розуміти, що таке [API](https://www.wikipedia.org/wiki/API) та [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), хоча б теоретично. + +## Оглядачі блоків {#block-explorers} + +Багато [оглядачів блоків](/developers/docs/data-and-analytics/block-explorers/) пропонують [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API)-шлюзи, які надають розробникам доступ до даних у реальному часі про блоки, транзакції, валідаторів, облікові записи та іншу ончейн-активність. + +Потім розробники можуть обробляти та перетворювати ці дані, щоб надати своїм користувачам унікальну аналітику та можливості взаємодії з [блокчейном](/glossary/#blockchain). Наприклад, [Etherscan](https://etherscan.io) та [Blockscout](https://eth.blockscout.com) надають дані про виконання та консенсус для кожного 12-секундного слоту. + +## The Graph {#the-graph} + +[The Graph](https://thegraph.com/) — це протокол індексування, який надає простий спосіб запиту даних блокчейну через відкриті API, відомі як субграфи. + +Завдяки The Graph розробники можуть отримати такі переваги: + +- Децентралізоване індексування: дає змогу індексувати дані блокчейну через кілька індексаторів, усуваючи таким чином будь-яку єдину точку відмови. +- Запити GraphQL: надає потужний інтерфейс GraphQL для запиту проіндексованих даних, що робить отримання даних надзвичайно простим. +- Налаштування: визначайте власну логіку для перетворення та зберігання даних блокчейну та повторно використовуйте субграфи, опубліковані іншими розробниками в мережі The Graph. + +Дотримуйтесь цього [посібника зі швидкого запуску](https://thegraph.com/docs/en/quick-start/), щоб створити, розгорнути та зробити запит до субграфу протягом 5 хвилин. + +## Різноманітність клієнтів {#client-diversity} + +[Різноманітність клієнтів](/developers/docs/nodes-and-clients/client-diversity/) важлива для загального стану мережі Ethereum, оскільки вона забезпечує стійкість до помилок та експлойтів. Зараз існує кілька інформаційних панелей щодо різноманітності клієнтів, зокрема [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) та [Ethernodes](https://ethernodes.org/). + +## Dune Analytics {#dune-analytics} + +[Dune Analytics](https://dune.com/) попередньо обробляє дані блокчейну в таблиці реляційної бази даних (DuneSQL), дає змогу користувачам робити запити до даних блокчейну за допомогою SQL і створювати інформаційні панелі на основі результатів запитів. Ончейн-дані організовано в 4 необроблені таблиці: `blocks`, `transactions`, (подій) `logs` та (викликів) `traces`. Популярні контракти та протоколи було розшифровано, і кожен має власний набір таблиць подій та викликів. Ці таблиці подій і викликів обробляються далі й організуються в таблиці абстракцій за типом протоколів, наприклад: dex, кредитування, стейблкоїни тощо. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) — це децентралізована, гіпермасштабована платформа даних, оптимізована для забезпечення ефективного, бездозвільного доступу до великих обсягів даних. Наразі вона надає історичні ончейн-дані, зокрема журнали подій, квитанції транзакцій, трасування та відмінності стану для кожної транзакції. SQD пропонує потужний інструментарій для створення спеціальних конвеєрів вилучення й обробки даних, досягаючи швидкості індексації до 150 тисяч блоків за секунду. + +Щоб почати, відвідайте [документацію](https://docs.sqd.dev/) або перегляньте [приклади для EVM](https://github.com/subsquid-labs/squid-evm-examples), щоб дізнатися, що можна створити за допомогою SQD. + +## Мережа SubQuery {#subquery-network} + +[SubQuery](https://subquery.network/) — це провідний індексатор даних, який надає розробникам швидкі, надійні, децентралізовані та налаштовувані API для їхніх проєктів Web3. SubQuery надає розробникам із понад 165 екосистем (включно з Ethereum) великі обсяги проіндексованих даних для створення інтуїтивно зрозумілого та захопливого досвіду для їхніх користувачів. Мережа SubQuery забезпечує роботу ваших нестримних застосунків за допомогою стійкої та децентралізованої інфраструктурної мережі. Використовуйте набір інструментів розробника блокчейну від SubQuery для створення Web3-застосунків майбутнього, не витрачаючи час на створення власного бекенду для обробки даних. + +Для початку відвідайте [посібник зі швидкого запуску для Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html), щоб почати індексувати дані блокчейну Ethereum за лічені хвилини в локальному середовищі Docker для тестування перед запуском у [керованому сервісі SubQuery](https://managedservice.subquery.network/) або в [децентралізованій мережі SubQuery](https://app.subquery.network/dashboard). + +## Мова запитів EVM {#evm-query-language} + +Мова запитів EVM (EQL) — це SQL-подібна мова, призначена для запитів до ланцюжків EVM (віртуальної машини Ethereum). Кінцева мета EQL — підтримувати складні реляційні запити до об’єктів першого класу ланцюжка EVM (блоків, облікових записів і транзакцій), надаючи розробникам і дослідникам ергономічний синтаксис для повсякденного використання. За допомогою EQL розробники можуть отримувати дані блокчейну, використовуючи знайомий SQL-подібний синтаксис, і усунути потребу в складному шаблонному коді. EQL підтримує стандартні запити до даних блокчейну (наприклад, отримання nonce та балансу облікового запису в Ethereum або отримання поточного розміру блоку та позначки часу) і постійно додає підтримку складніших запитів та наборів функцій. + +## Додаткові матеріали {#further-reading} + +- [Дослідження криптоданих I: архітектури потоків даних](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Огляд мережі The Graph](https://thegraph.com/docs/en/about/) +- [Тестове середовище для запитів The Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Приклади коду API на EtherScan](https://etherscan.io/apis#contracts) +- [Документація API на Blockscout](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in — оглядач Beacon Chain](https://beaconcha.in) +- [Основи Dune](https://docs.dune.com/#dune-basics) +- [Посібник зі швидкого запуску SubQuery для Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Огляд мережі SQD](https://docs.sqd.dev/) +- [Мова запитів EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/uk/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/uk/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..ebff8238551 --- /dev/null +++ b/public/content/translations/uk/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "Стратегії зберігання даних на блокчейні" +description: "Існує кілька способів зберігання даних за допомогою блокчейну. У цій статті ми порівняємо різні стратегії, їхні витрати та компроміси, а також вимоги для їх безпечного використання." +lang: uk +--- + +Існує кілька способів зберігання інформації як безпосередньо в блокчейні, так і у спосіб, що забезпечується блокчейном: + +- блоби EIP-4844 +- Calldata +- Offchain з механізмами L1 +- «Код» контракту +- Події +- Сховище EVM + +Вибір методу залежить від кількох критеріїв: + +- Джерело інформації. Інформація в calldata не може надходити безпосередньо із самого блокчейну. +- Призначення інформації. Calldata доступна тільки в транзакції, яка її містить. Події взагалі недоступні в ланцюжку. +- Наскільки прийнятними є труднощі? Комп'ютери, на яких працює повноцінний вузол, можуть виконувати більше обробки, ніж легкий клієнт у застосунку, що працює в браузері. +- Чи необхідно забезпечити легкий доступ до інформації з кожного вузла? +- Вимоги до безпеки. + +## Вимоги до безпеки {#security-requirements} + +Загалом інформаційна безпека складається з трьох атрибутів: + +- _Конфіденційність_, неавторизованим суб'єктам заборонено читати інформацію. Це важливо в багатьох випадках, але не в цьому. _На блокчейні немає секретів_. Блокчейни працюють, тому що будь-хто може перевірити переходи станів, тому їх неможливо використовувати для безпосереднього зберігання секретів. Існують способи зберігання конфіденційної інформації в блокчейні, але всі вони покладаються на якийсь offchain-компонент для зберігання принаймні ключа. + +- _Цілісність_, інформація є правильною, вона не може бути змінена неавторизованими суб'єктами або несанкціонованими способами (наприклад, передача [токенів ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) без події `Transfer`). У блокчейні кожен вузол перевіряє кожну зміну стану, що забезпечує цілісність. + +- _Доступність_, інформація доступна будь-якому авторизованому суб'єкту. У блокчейні це зазвичай досягається завдяки тому, що інформація доступна на кожному [повному вузлі](https://ethereum.org/developers/docs/nodes-and-clients#full-node). + +Різні рішення тут мають відмінну цілісність, оскільки хеші публікуються на L1. Однак вони мають різні гарантії доступності. + +## Передумови {#prerequisites} + +Ви повинні добре розуміти [основи блокчейну](/developers/docs/intro-to-ethereum/). Ця сторінка також передбачає, що читач знайомий з [блоками](/developers/docs/blocks/), [транзакціями](/developers/docs/transactions/) та іншими відповідними темами. + +## блоби EIP-4844 {#eip-4844-blobs} + +Починаючи з [хардфорку Dencun](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md), блокчейн Ethereum включає [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), який додає до Ethereum блоби даних з обмеженим терміном зберігання (спочатку близько [18 днів](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). Ціна на ці блоби встановлюється окремо від [газу за виконання](/developers/docs/gas), хоча використовується схожий механізм. Це дешевий спосіб опублікувати тимчасові дані. + +Основний варіант використання блобів EIP-4844 — це публікація транзакцій ролапами. [Оптимістичні ролапи](/developers/docs/scaling/optimistic-rollups) повинні публікувати транзакції у своїх блокчейнах. Ці транзакції мають бути доступними для будь-кого протягом [періоду оскарження](https://docs.optimism.io/connect/resources/glossary#challenge-period), щоб [валідатори](https://docs.optimism.io/connect/resources/glossary#validator) могли виправити помилку, якщо [секвенсер](https://docs.optimism.io/connect/resources/glossary#sequencer) ролапу опублікує неправильний корінь стану. + +Однак, коли період оскарження минув і корінь стану фіналізовано, решта призначення знання цих транзакцій полягає у відтворенні поточного стану ланцюжка. Цей стан також доступний з вузлів ланцюжка, що потребує значно менше обробки. Тож інформація про транзакції все ще має зберігатися в кількох місцях, наприклад, в [оглядачах блоків](/developers/docs/data-and-analytics/block-explorers), але немає потреби платити за рівень стійкості до цензури, який забезпечує Ethereum. + +[Ролапи з нульовим розголошенням](/developers/docs/scaling/zk-rollups/#data-availability) також публікують дані своїх транзакцій, щоб дозволити іншим вузлам відтворювати існуючий стан і перевіряти докази дійсності, але це знову ж таки короткострокова вимога. + +На момент написання статті публікація в EIP-4844 коштує один wei (10-18 ETH) за байт, що є незначним порівняно з [21 000 газу за виконання, які коштує будь-яка транзакція, включно з тією, що публікує блоби](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Ви можете побачити поточну ціну EIP-4844 на [blobscan.com](https://blobscan.com/blocks). + +Ось адреси, за якими можна побачити блоби, опубліковані деякими відомими ролапами. + +| Rollup | Адреса поштової скриньки | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata — це байти, що надсилаються як частина транзакції. Вони зберігаються як частина постійного запису блокчейну в блоці, який містить цю транзакцію. + +Це найдешевший спосіб назавжди розмістити дані в блокчейні. Вартість одного байта становить або 4 газу за виконання (якщо байт дорівнює нулю), або 16 газу (будь-яке інше значення). Якщо дані стиснуті, що є стандартною практикою, то кожне значення байта є однаково ймовірним, тому середня вартість становить приблизно 15,95 газу за байт. + +На момент написання статті ціни становлять 12 gwei/газ і 2300 $/ETH, що означає, що вартість становить приблизно 45 центів за кілобайт. Оскільки це був найдешевший метод до EIP-4844, це метод, який ролапи використовували для зберігання інформації про транзакції, яка має бути доступна для [оскаржень несправностей](https://docs.optimism.io/stack/protocol/overview#fault-proofs), але не потребує прямого доступу в ланцюжку. + +Ось адреси, за якими можна побачити транзакції, опубліковані деякими відомими ролапами. + +| Rollup | Адреса поштової скриньки | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Offchain з механізмами L1 {#offchain-with-l1-mechs} + +Залежно від ваших компромісів у сфері безпеки, може бути прийнятним розміщувати інформацію в іншому місці та використовувати механізм, який забезпечує доступність даних за потреби. Для цього необхідно виконати дві вимоги: + +1. Опублікувати [хеш](https://en.wikipedia.org/wiki/Cryptographic_hash_function) даних у блокчейні, що називається _зобов'язанням щодо вхідних даних_. Це може бути одне 32-байтне слово, тому це недорого. Доки зобов'язання щодо вхідних даних доступне, цілісність гарантується, оскільки неможливо знайти інші дані, які б хешувалися до того ж значення. Тому, якщо надано неправильні дані, це можна виявити. + +2. Мати механізм, що забезпечує доступність. Наприклад, у [Redstone](https://redstone.xyz/docs/what-is-redstone) будь-який вузол може подати запит на перевірку доступності. Якщо секвенсер не надасть відповідь в ланцюжку до встановленого терміну, зобов'язання щодо вхідних даних відкидається, тому інформація вважається такою, що ніколи не була опублікована. + +Це прийнятно для оптимістичного ролапу, оскільки ми вже покладаємося на наявність принаймні одного чесного верифікатора для кореня стану. Такий чесний верифікатор також переконається, що він має дані для обробки блоків, і видасть запит на перевірку доступності, якщо інформація не доступна поза ланцюжком. Цей тип оптимістичного ролапу називається [плазма](/developers/docs/scaling/plasma/). + +## Код контракту {#contract-code} + +Інформація, яку потрібно записати лише один раз, яка ніколи не перезаписується і має бути доступна в ланцюжку, може зберігатися як код контракту. Це означає, що ми створюємо «смартконтракт» із даними, а потім використовуємо [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) для читання інформації. Перевага в тому, що копіювання коду є відносно дешевим. + +Окрім вартості розширення пам'яті, `EXTCODECOPY` коштує 2600 газу за перший доступ до контракту (коли він «холодний») і 100 газу за наступні копії з того самого контракту плюс 3 газу за 32-байтне слово. Порівняно з calldata, вартість якої становить 15,95 за байт, це дешевше, починаючи приблизно з 200 байтів. Згідно з [формулою вартості розширення пам'яті](https://www.evm.codes/about#memoryexpansion), доки вам не потрібно більше 4 МБ пам'яті, вартість розширення пам'яті менша за вартість додавання calldata. + +Звісно, це лише вартість _читання_ даних. Створення контракту коштує приблизно 32 000 газу + 200 газу/байт. Цей метод є економічним лише тоді, коли ту саму інформацію потрібно читати багато разів у різних транзакціях. + +Код контракту може бути безглуздим, якщо він не починається з `0xEF`. Контракти, що починаються з `0xEF`, інтерпретуються як [об'єктний формат Ethereum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), який має значно суворіші вимоги. + +## Події {#events} + +[Події](https://docs.alchemy.com/docs/solidity-events) генеруються смартконтрактами і читаються програмним забезпеченням поза ланцюжком. +Їхня перевага в тому, що код поза ланцюжком може прослуховувати події. Вартість становить [газ](https://www.evm.codes/#a0?fork=cancun), 375 плюс 8 газу за байт даних. При ціні 12 gwei/газ і 2300 $/ETH це становить один цент плюс 22 центи за кілобайт. + +## Сховище {#storage} + +Смартконтракти мають доступ до [постійного сховища](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Однак це дуже дорого. Запис 32-байтного слова в раніше порожній слот сховища може [коштувати 22 100 газу](https://www.evm.codes/#55?fork=cancun). При ціні 12 gwei/газ і 2300 $/ETH це становить близько 61 цента за операцію запису, або 19,5 долара за кілобайт. + +Це найдорожча форма зберігання в Ethereum. + +## Підсумок {#summary} + +У цій таблиці підсумовано різні варіанти, їхні переваги та недоліки. + +| Тип сховища | Джерело даних | Гарантія доступності | Доступність у ланцюжку | Додаткові обмеження | +| ------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | -------------------------------------------------------------------- | +| блоби EIP-4844 | Offchain | Гарантія Ethereum на [~18 днів](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Доступний лише хеш | | +| Calldata | Offchain | Гарантія Ethereum назавжди (частина блокчейну) | Доступно лише за умови запису в контракт і в цій транзакції | | +| Offchain з механізмами L1 | Offchain | Гарантія «одного чесного верифікатора» протягом періоду оскарження | Лише хеш | Гарантується механізмом оскарження, лише протягом періоду оскарження | +| Код контракту | Onchain або offchain | Гарантія Ethereum назавжди (частина блокчейну) | Так | Записується на «випадкову» адресу, не може починатися з `0xEF` | +| Події | Onchain | Гарантія Ethereum назавжди (частина блокчейну) | Ні | | +| Сховище | Onchain | Гарантія Ethereum назавжди (частина блокчейну та поточного стану до перезапису) | Так | | diff --git a/public/content/translations/uk/developers/docs/data-availability/index.md b/public/content/translations/uk/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..31328407ed2 --- /dev/null +++ b/public/content/translations/uk/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "Доступність даних" +description: "Огляд проблем і рішень, пов'язаних із доступністю даних в Ethereum" +lang: uk +--- + +"Не довіряй, а перевіряй" — це поширена максима в Ethereum. Ідея полягає в тому, що ваш вузол може незалежно перевіряти правильність отриманої інформації, виконуючи всі транзакції в блоках, які він отримує від вузлів-учасників, щоб гарантувати, що запропоновані зміни точно відповідають тим, які були обчислені незалежно вузлом. Це означає, що вузлам не потрібно довіряти чесності відправників блоку. Це неможливо, якщо дані відсутні. + +**Доступність даних** означає впевненість користувача в тому, що дані, необхідні для перевірки блоку, дійсно доступні для всіх учасників мережі. Для повних вузлів на першому рівні Ethereum це відносно просто; повний вузол завантажує копію всіх даних у кожному блоці — дані _мають_ бути доступними, щоб завантаження стало можливим. Блок із відсутніми даними буде відхилено, а не додано до блокчейну. Це "ончейн-доступність даних" і є особливістю монолітних блокчейнів. Повні вузли неможливо змусити приймати недійсні транзакції, оскільки вони самостійно завантажують і виконують кожну транзакцію. Однак для модульних блокчейнів, зведень рівня 2 і легких клієнтів ситуація з доступністю даних є складнішою, що вимагає більш досконалих процедур перевірки. + +## Передумови {#prerequisites} + +Вам слід добре розбиратися в [основах блокчейну](/developers/docs/intro-to-ethereum/), особливо в [механізмах досягнення консенсусу](/developers/docs/consensus-mechanisms/). На цій сторінці також передбачається, що читач знайомий із [блоками](/developers/docs/blocks/), [транзакціями](/developers/docs/transactions/), [вузлами](/developers/docs/nodes-and-clients/), [рішеннями для масштабування](/developers/docs/scaling/) й іншими відповідними темами. + +## Проблема доступності даних {#the-data-availability-problem} + +Проблема доступності даних — це необхідність довести всій мережі, що узагальнена форма деяких даних транзакцій, які додаються до блокчейну, дійсно являє собою набір дійсних транзакцій, але зробити це, не вимагаючи від усіх вузлів завантажувати всі дані. Повні дані транзакцій необхідні для незалежної перевірки блоків, але вимога до всіх вузлів завантажувати всі дані транзакцій є перешкодою для масштабування. Рішення проблеми доступності даних спрямовані на надання достатніх гарантій того, що повні дані транзакцій були доступні для перевірки учасникам мережі, які не завантажують і не зберігають ці дані самостійно. + +[Легкі вузли](/developers/docs/nodes-and-clients/light-clients) та [зведення рівня 2](/developers/docs/scaling) є важливими прикладами учасників мережі, які потребують надійних гарантій доступності даних, але не можуть самостійно завантажувати й обробляти дані транзакцій. Уникнення завантаження даних транзакцій — це те, що робить легкі вузли легкими та дає змогу зведенням бути ефективними рішеннями для масштабування. + +Доступність даних також є критичною проблемою для майбутніх клієнтів Ethereum ["без стану"](/roadmap/statelessness), яким не потрібно завантажувати та зберігати дані стану для перевірки блоків. Клієнти без стану все одно мають бути впевнені, що дані доступні _де-небудь_ і що вони були оброблені правильно. + +## Рішення щодо доступності даних {#data-availability-solutions} + +### Вибірка для перевірки доступності даних (DAS) {#data-availability-sampling} + +Вибірка для перевірки доступності даних (DAS) — це спосіб перевірки мережею доступності даних без надмірного навантаження на окремі вузли. Кожен вузол (включно з вузлами, що не беруть участь у стейкінгу) завантажує невеликий, випадково вибраний фрагмент загальних даних. Успішне завантаження вибірок з високою впевненістю підтверджує, що всі дані доступні. Це ґрунтується на кодуванні з виправленням помилок, яке розширює певний набір даних надлишковою інформацією (це робиться шляхом підбору функції, відомої як _поліном_, до даних і обчислення цього полінома в додаткових точках). Це дає змогу за потреби відновити вихідні дані з надлишкових. Наслідком такого створення даних є те, що якщо _будь-які_ з вихідних даних недоступні, _половина_ розширених даних буде відсутня! Кількість вибірок даних, що завантажуються кожним вузлом, можна налаштувати так, щоб було _надзвичайно_ ймовірно, що принаймні один із фрагментів даних, відібраних кожним клієнтом, буде відсутнім, _якщо_ насправді доступно менше половини даних. + +DAS використовуватиметься для того, щоб оператори зведень робили дані своїх транзакцій доступними після впровадження [повного Danksharding](/roadmap/danksharding/#what-is-danksharding). Вузли Ethereum будуть випадковим чином відбирати дані транзакцій, надані в блобах, використовуючи описану вище схему надлишковості, щоб переконатися, що всі дані існують. Цей самий метод можна також використовувати, щоб гарантувати, що виробники блоків роблять усі свої дані доступними для захищених легких клієнтів. Аналогічно, у разі [розділення пропонента та конструктора](/roadmap/pbs) тільки конструктор блоків повинен буде обробляти весь блок — інші валідатори будуть виконувати перевірку за допомогою вибірки для перевірки доступності даних. + +### Комітети з доступності даних {#data-availability-committees} + +Комітети з доступності даних (DAC) — це довірені сторони, які забезпечують або підтверджують доступність даних. Комітети з доступності даних (DAC) можна використовувати замість DAS [або в поєднанні з ним](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). Гарантії безпеки, які надають комітети, залежать від конкретної конфігурації. Наприклад, Ethereum використовує випадково вибрані підмножини валідаторів для підтвердження доступності даних для легких вузлів. + +DAC також використовуються деякими валідіумами. DAC — це довірений набір вузлів, що зберігає копії даних поза мережею. У разі суперечки DAC зобов’язаний надати доступ до даних. Члени DAC також публікують ончейн-атестації, щоб довести, що зазначені дані дійсно доступні. Деякі валідіуми замінюють DAC системою валідаторів на основі доказу частки володіння (PoS). Тут будь-хто може стати валідатором і зберігати дані поза мережею. Однак вони повинні надати «заставу», яка вноситься в смарт-контракт. У разі зловмисної поведінки, як-от утримання даних валідатором, застава може бути конфіскована. Комітети з доступності даних на основі доказу частки володіння значно безпечніші за звичайні DAC, оскільки вони безпосередньо стимулюють чесну поведінку. + +## Доступність даних і легкі вузли {#data-availability-and-light-nodes} + +[Легким вузлам](/developers/docs/nodes-and-clients/light-clients) необхідно перевіряти правильність отриманих заголовків блоків, не завантажуючи дані блоків. Ціною такої легкості є неможливість незалежної перевірки заголовків блоків шляхом повторного локального виконання транзакцій, як це роблять повні вузли. + +Легкі вузли Ethereum довіряють випадковим наборам із 512 валідаторів, які були призначені до _комітету синхронізації_. Комітет синхронізації діє як DAC, який за допомогою криптографічного підпису сигналізує легким клієнтам про правильність даних у заголовку. Щодня комітет синхронізації оновлюється. Кожен заголовок блоку сповіщає легкі вузли про те, які валідатори повинні підписати _наступний_ блок, тому їх неможливо обманом змусити довіряти зловмисній групі, яка видає себе за справжній комітет синхронізації. + +Однак що станеться, якщо зловмисник якимось чином _зможе_ передати зловмисний заголовок блоку легким клієнтам і переконати їх, що його підписав чесний комітет синхронізації? У такому разі зловмисник може включити недійсні транзакції, і легкий клієнт сліпо прийме їх, оскільки він не перевіряє самостійно всі зміни стану, узагальнені в заголовку блоку. Щоб захиститися від цього, легкий клієнт може використовувати докази шахрайства. + +Спосіб роботи цих доказів шахрайства полягає в тому, що повний вузол, побачивши недійсний перехід стану, що поширюється мережею, може швидко згенерувати невеликий фрагмент даних, який демонструє, що запропонований перехід стану не міг виникнути з певного набору транзакцій, і транслювати ці дані іншим учасникам. Легкі вузли можуть підхоплювати ці докази шахрайства та використовувати їх для відхилення поганих заголовків блоків, гарантуючи, що вони залишаться на тому ж чесному ланцюжку, що й повні вузли. + +Це залежить від того, чи мають повні вузли доступ до повних даних транзакцій. Зловмисник, який транслює поганий заголовок блоку, а також не надає доступ до даних транзакцій, зможе перешкодити повним вузлам генерувати докази шахрайства. Повні вузли могли б попередити про поганий блок, але вони не змогли б підкріпити своє попередження доказом, оскільки дані для генерації доказу не були надані! + +Рішенням цієї проблеми доступності даних є DAS. Легкі вузли завантажують дуже маленькі випадкові фрагменти повних даних стану та використовують ці вибірки для перевірки доступності повного набору даних. Фактичну ймовірність неправильного припущення про повну доступність даних після завантаження N випадкових фрагментів можна обчислити ([для 100 фрагментів імовірність становить 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), тобто неймовірно мало). + +Навіть за такого сценарію атаки, що приховують лише кілька байтів, можуть залишитися непоміченими клієнтами, які роблять випадкові запити даних. Кодування з виправленням помилок вирішує цю проблему, відновлюючи невеликі відсутні фрагменти даних, які можна використовувати для перевірки запропонованих змін стану. Потім можна було б створити доказ шахрайства з використанням відновлених даних, що завадило б легким вузлам приймати погані заголовки. + +**Примітка:** DAS і докази шахрайства ще не реалізовані для легких клієнтів Ethereum на основі доказу частки володіння, але вони є в плані розвитку і, найімовірніше, будуть реалізовані у формі доказів на основі ZK-SNARK. Сьогоднішні легкі клієнти покладаються на одну з форм DAC: вони перевіряють ідентичність комітету синхронізації, а потім довіряють отриманим підписаним заголовкам блоків. + +## Доступність даних і зведення рівня 2 {#data-availability-and-layer-2-rollups} + +[Рішення для масштабування рівня 2](/layer-2/), такі як [зведення](/glossary/#rollups), знижують вартість транзакцій і збільшують пропускну здатність Ethereum шляхом обробки транзакцій поза мережею. Транзакції зведень стискаються та публікуються в Ethereum пакетами. Пакети являють собою тисячі окремих транзакцій поза мережею в одній транзакції в Ethereum. Це зменшує перевантаження на базовому рівні та знижує комісії для користувачів. + +Однак довіряти «зведеним» транзакціям, опублікованим в Ethereum, можна лише в тому випадку, якщо запропоновану зміну стану можна незалежно перевірити та підтвердити, що вона є результатом застосування всіх окремих транзакцій поза мережею. Якщо оператори зведень не нададуть дані транзакцій для цієї перевірки, вони можуть надіслати в Ethereum некоректні дані. + +[Оптимістичні зведення](/developers/docs/scaling/optimistic-rollups/) публікують стислі дані транзакцій в Ethereum і чекають певний час (зазвичай 7 днів), щоб незалежні верифікатори могли перевірити дані. Якщо хтось виявить проблему, він може згенерувати доказ шахрайства та використати його, щоб оскаржити зведення. Це призведе до відкату ланцюжка та пропуску недійсного блоку. Це можливо лише за умови доступності даних. Наразі існує два способи, якими оптимістичні зведення публікують дані транзакцій на рівні 1. Деякі зведення роблять дані постійно доступними як `CALLDATA`, які постійно знаходяться в мережі. Після впровадження EIP-4844 деякі зведення замість цього публікують дані своїх транзакцій у дешевшому сховищі блобів. Це не постійне сховище. Незалежні верифікатори повинні зробити запит до блобів і висунути свої оскарження протягом ~18 днів, перш ніж дані будуть видалені з рівня 1 Ethereum. Протокол Ethereum гарантує доступність даних лише протягом цього короткого фіксованого вікна. Після цього відповідальність лягає на інші суб’єкти екосистеми Ethereum. Будь-який вузол може перевірити доступність даних за допомогою DAS, тобто завантажуючи невеликі випадкові вибірки даних блобів. + +[Зведення з нульовим розголошенням (ZK)](/developers/docs/scaling/zk-rollups) не потребують публікації даних транзакцій, оскільки [докази дійсності з нульовим розголошенням](/glossary/#zk-proof) гарантують правильність переходів стану. Однак доступність даних все ще є проблемою, оскільки ми не можемо гарантувати функціональність ZK-зведення (або взаємодіяти з ним) без доступу до даних його стану. Наприклад, користувачі не можуть дізнатися свої баланси, якщо оператор приховує деталі про стан зведення. Крім того, вони не можуть виконувати оновлення стану, використовуючи інформацію, що міститься в новому доданому блоці. + +## Доступність даних у порівнянні з можливістю їх вилучення {#data-availability-vs-data-retrievability} + +Доступність даних відрізняється від можливості їх вилучення. Доступність даних — це гарантія того, що повні вузли змогли отримати доступ і перевірити повний набір транзакцій, пов’язаних із певним блоком. Це не обов’язково означає, що дані будуть доступні завжди. + +Можливість вилучення даних — це здатність вузлів отримувати _історичну інформацію_ з блокчейну. Ці історичні дані не потрібні для перевірки нових блоків, вони потрібні лише для синхронізації повних вузлів із первинного блоку або для обслуговування конкретних історичних запитів. + +Основний протокол Ethereum насамперед пов’язаний із доступністю даних, а не з можливістю їх вилучення. Можливість вилучення даних може бути забезпечена невеликою кількістю архівних вузлів, що керуються третіми сторонами, або може бути розподілена по всій мережі з використанням децентралізованого файлового сховища, такого як [Portal Network](https://www.ethportal.net/). + +## Для подальшого читання {#further-reading} + +- [Що таке доступність даних?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Що таке доступність даних?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Основи перевірок доступності даних](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Пояснення пропозиції щодо шардингу + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Примітка про доступність даних і кодування з виправленням помилок](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Комітети з доступності даних.](https://medium.com/starkware/data-availability-e5564c416424) +- [Комітети з доступності даних на основі доказу частки володіння.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Рішення проблеми вилучення даних](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Доступність даних, або Як зведення навчилися не хвилюватися і полюбили 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) +- [EIP-7623: Збільшення вартості Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/uk/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/uk/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..34f6cbd017b --- /dev/null +++ b/public/content/translations/uk/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "Структури даних і кодування" +description: "Огляд фундаментальних структур даних Ethereum." +lang: uk +sidebarDepth: 2 +--- + +Ethereum створює, зберігає та передає великі обсяги даних. Ці дані мають бути відформатовані стандартизованими та ефективними з точки зору пам'яті способами, щоб будь-хто міг [запустити вузол](/run-a-node/) на відносно скромному обладнанні споживчого класу. Для цього в стеку Ethereum використовуються кілька специфічних структур даних. + +## Передумови {#prerequisites} + +Ви повинні розуміти основи Ethereum та [клієнтського програмного забезпечення](/developers/docs/nodes-and-clients/). Рекомендується ознайомитися з мережевим рівнем і [технічним документом Ethereum](/whitepaper/). + +## Структури даних {#data-structures} + +### Patricia Merkle Tries {#patricia-merkle-tries} + +Patricia Merkle Tries — це структури, які кодують пари «ключ-значення» в детерміноване та криптографічно автентифіковане префіксне дерево. Вони широко використовуються на виконавчому рівні Ethereum. + +[Докладніше про Patricia Merkle Tries](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Recursive Length Prefix {#recursive-length-prefix} + +Recursive Length Prefix (RLP) — це метод серіалізації, який широко використовується на виконавчому рівні Ethereum. + +[Докладніше про RLP](/developers/docs/data-structures-and-encoding/rlp) + +### Simple Serialize {#simple-serialize} + +Simple Serialize (SSZ) — це домінантний формат серіалізації на рівні консенсусу Ethereum через його сумісність із меркелізацією. + +[Докладніше про SSZ](/developers/docs/data-structures-and-encoding/ssz)