Вступ

За приблизно місяць, #Bitcoin is set to begin its next halving. However, the author believes Сатоші Накамото’s vision—consensus accessible to everyone via CPU—has yet to be realized. In this regard, the iterative mechanisms of Arweave may align more faithfully with Накамото’s original vision, with version 2.6 representing a significant step towards fulfilling his expectations. This version brings substantial improvements over its predecessors, aiming to:

• Обмежте апаратне прискорення, дозволяючи забезпечити підтримку згоди за допомогою універсального ЦП + механічного жорсткого диска, тим самим зменшуючи витрати на зберігання;
• Спрямовуйте витрати на пряму згоду на ефективне зберігання даних, а не на енергоємне хеш-змагання;
• Заохочувати рударів встановлювати свої повні копії наборів даних Arweave, що дозволяє швидший маршрутизацію даних та більш розподілене зберігання.

Механізм консенсусу

З урахуванням вищезазначених цілей, механізм версії 2.6 приблизно наступний:

• До первинного механізму SPoRA додається новий компонент, який називається Хеш-ланцюг та генерує геш SHA-256 кожну секунду за допомогою згаданого раніше алгоритму шифрування.
• Майнер вибирає індекс розділу в розділі даних, який він зберігає, і використовує його разом з хешем майнінгу та адресою майнінгу як вхідну інформацію для початку майнінгу.
• Створіть діапазон виклику 1 в обраному розділі та інший діапазон виклику 2 у випадковому положенні в переплетеній мережі.
• Використовуйте блоки даних відгуків (частини) в межах 1 послідовно, щоб розрахувати, чи є це рішення блоку. Якщо результат обчислення перевищує поточну складність мережі, рудар набуває право на видобуток; якщо це не вдається, перейдіть до розрахунку наступного блоку відгуку в діапазоні.
• Записи даних у діапазоні 2 також можуть бути обчислені та перевірені, але їхні рішення потребують хешу з діапазону 1.

Графік 1: Схема Механізму Консенсусу в Версії 2.6

Давайте ознайомимось з різними термінами та концепціями, які зустрічаються у цьому механізмі:

Дані Arweave: Також відомий як «Мережа Weave». Усі дані в мережі розділені на окремі блоки даних, які називаються Частинами (блоки нагадують «цегляний мур» на діаграмі). Ці блоки рівномірно розподілені по всій мережі Arweave і адресуються за допомогою структури дерева Меркла (також відомої як Глобальний зсув), що дозволяє ідентифікувати позицію будь-якого блоку даних в мережі Weave.

Chunk: Кожний блок даних зазвичай має розмір 256 КБ. Майнери повинні упаковувати та хешувати відповідні блоки даних, щоб виграти право на видобуток, доводячи, що вони зберігають копії даних під час процесу видобутку за SPoRA.

Розділ: "Розділ" - це нове поняття, введене в версії 2.6. Кожен розділ охоплює 3,6 ТБ даних. Розділи пронумеровані з початку мережі Weave (індекс 0) до загальної кількості розділів, які охоплюють всю мережу Weave.

Діапазон відкликання: Діапазон відкликання - це ще одна нова концепція в версії 2.6. Він представляє собою серію континуальних блоків даних (Чанки) в мережі Weave, починаючи з конкретного зсуву і маючи довжину 100 МБ. Кожен блок даних становить 256 КБ, а в Діапазон відкликання входить 400 блоків даних. У цьому механізмі є два Діапазони відкликання, як пояснено докладніше нижче.

Потенційні рішення: Кожен 256KB блок даних в межах діапазону Recall вважається потенційним рішенням для виграшу права на видобуток. У процесі видобутку кожен блок даних хешується для перевірки відповідності вимогам складності мережі. У разі успіху майнер виграє право на видобуток і отримує винагороду за видобуток. У випадку невдачі майнер продовжує намагатися наступний 256KB блок в межах діапазону Recall.

Ланцюжок хешів: Ланцюжок хешів - це ключове оновлення у версії 2.6, яке додає зашифрований годинник до попереднього SPoRA, обмежуючи максимальну швидкість хешування. Ланцюжок хешів генерує послідовність хешів шляхом послідовного хешування частини даних за допомогою функції SHA-256. Цей процес не може бути паралелізований (легко досяжний за допомогою процесорів для споживачів), досягаючи затримки 1 секунду шляхом виконання певної кількості послідовних операцій хешування.

Хешування: Після достатньої кількості послідовних операцій хешування (тобто після затримки в 1 секунду) Ланцюг Хешів формує хеш-значення, вважається дійсним для видобутку. Варто зауважити, що хеш для видобутку є однаковим для всіх майнерів, і всі майнери можуть його перевірити.

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

Кращі стратегії

Загальна мета Arweave була вже введена кілька разів, а саме максимізувати кількість реплік даних, збережених в мережі. Але що зберігати? Як це зберігати? В це включено багато вимог і дрібниць. Тут ми обговоримо, як прийняти стратегію кращої практики.

Репліки проти копій

З версії 2.6 я часто зустрічав два терміни в різних технічних документах: Репліки та Копії. Обидва поняття можуть бути перекладені як "копії" на китайську мову, але насправді між ними є значні відмінності, які також спричинили деякі перешкоди для мене в розумінні механізму. З метою спрощення розуміння я вважаю за краще перекладати Репліки як "копії" (репліки) та Копії як "резервні копії" (резервні копії).

Копії відносяться просто до копіювання даних, де не існує різниці між резервними копіями тих самих даних.

Репліки, з іншого боку, підкреслюють унікальність. Це вказує на те, що дані зберігаються після проходження процесу унікальності. Мережа Arweave підтримує зберігання реплік, а не просто резервних копій.

Примітка: У версії 2.7 механізм консенсусу було змінено на SPoRes, що означає Короткі докази реплікацій, засновані на зберіганні реплік. Я надам подальше пояснення у майбутньому.

Упаковка унікальних реплік

Унікальні репліки є важливими в механізмі Arweave. Шахтарі повинні упаковувати всі дані у певному форматі, щоб сформувати свої унікальні репліки як обов'язкову умову для виграшу права на видобуток.

Якщо ви хочете запустити новий вузол і думаєте про пряме копіювання даних, які вже упакували інші майнери, це не працюватиме. Спочатку потрібно завантажити та синхронізувати початкові дані з мережі Arweave Weave (звісно, вам не потрібно завантажувати все, завантаження лише частини також є можливим, і ви можете встановити власні політики щодо даних для відсіювання ризикових даних). Потім використовуйте функцію RandomX для упаковки кожного блоку початкових даних, перетворюючи їх у потенційні рішення для майнінгу.

Процес упаковки передбачає надання ключа упаковки функції RandomX, що дозволяє йому генерувати результати через кілька обчислень для упаковки початкових блоків даних. Процес розпакування вже упакованих блоків даних однаковий - надання ключа упаковки та використання результатів, отриманих через кілька обчислень, для розпакування блоків даних.

У версії 2.5 резервне копіювання ключа упаковки - це хеш SHA256, пов'язаний з chunk_offset (зміщенням блока даних, також розуміється як параметр позиції блока даних) та tx_root (коренем транзакції). Це забезпечує, що кожне добуте рішення з видобутку походить з унікальної репліки блоків даних у межах конкретного блоку. Якщо блок даних має кілька резервних копій в різних місцях у розбитій мережі, кожна резервна копія повинна бути резервною копією окремо як унікальна репліка.

У версії 2.6 цей резервний ключ розширюється до хешу SHA256, пов'язаного з chunk_offset, tx_root та miner_address (адреса майнера). Це означає, що кожна репліка також є унікальною для кожної адреси майнінгу.

Переваги зберігання повних реплік

Алгоритм вказує, що рударі повинні створювати унікальну повну репліку, а не частково репліковані, що забезпечує рівномірне розподіл даних по всій мережі.

Як нам слід це розуміти? Давайте зрозуміємо через порівняння наступних двох зображень.

Спочатку припустимо, що весь фрагментований мережі Arweave виробив загальну кількість 16 частин даних.

Сценарій 1:

• Шахтар Боб виявив, що завантаження даних занадто часомістке, тому він завантажив лише дані з перших 4 розділів розірваної мережі.
• Щоб максимізувати видобуток реплік в цих 4 розділах, Боб придумав хитру ідею. Він зробив 4 копії даних з цих 4 розділів і згрупував їх в 4 унікальні ресурси реплік, використовуючи різні адреси для майнінгу. Тепер у Боба є 16 розділів у його сховищі. Це добре і відповідає правилам унікальних реплік.
• Далі, Боб може проводити тести на порушення для кожного блоку матеріалу даних у кожному розділі кожну секунду при отриманні хеша майнінгу. Це дозволяє Бобу мати 400 * 16 = 6400 потенційних рішень для майнінгу за одну секунду.
• Але розум Боба коштує, оскільки він повинен пожертвувати одну можливість для кожного діапазону згадувань. Бачите ці "знаки питання"? Вони представляють другий діапазон згадувань, який Боб не може знайти на своєму жорсткому диску, оскільки це позначає розділи даних, які Боб не зберіг. Звичайно, з удачею, є відносно низькі показники, які символізують те, що Боб зберіг лише 25% з 4 розділів, що означає 1600 потенційних рішень.
• Таким чином, ця стратегія дозволяє Бобу мати 6400 + 1600 = 8000 потенційних рішень за секунду.

Фігура 2: "Хитра" стратегія Боба: Перший сценарій

Другий сценарій:

Зараз давайте розглянемо другий сценарій. Завдяки розташуванню двох діапазонів відгуків більш оптимальною стратегією є зберігання унікальних реплік даних з більшими проблемами. Це показано на рисунку 3.

• Майнерка Аліса, на відміну від “розумного” підходу Боба, старанно завантажує дані розділу для всіх 16 розділів та використовує лише одну адресу для видобутку, щоб створити унікальну репліку з 16 резервними копіями.
• Оскільки у Еліси також 16 розділів, загальна потенційна кількість рішень для першого діапазону виклику така сама, як у Боба, а саме 6400.
• Однак у цьому сценарії Еліс отримує всі потенційні рішення для другого діапазону виклику. Це додатково 6400.
• Таким чином, стратегія Еліс дає їй 6400 + 6400 = 12800 потенційних рішень на секунду. Перевага очевидна.

Рисунок 3: Стратегія Еліс має більші переваги

Роль діапазонів виклику

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

Причина досить проста: діапазон викликів складається з суміжних блоків даних, і ця структура служить одній основній меті - мінімізувати рух читаючої головки механічних жорстких дисків (HDD). Цей метод фізичної оптимізації дозволяє досягти продуктивності читання HDD на рівні більш дорогих твердотілих накопичувачів (SSD). Це схоже на те, що ви обмежуєте одну руку та одну ногу SSD; звичайно, він все ще може мати невеличку швидкісну перевагу, можучи передавати чотири діапазони викликів за секунду. Однак, порівняно з дешевшими HDD, їх кількість буде ключовою метрикою, яка визначатиме вибір майнерів.

Перевірка ланцюжка хешів

Тепер давайте обговоримо підтвердження нового блоку.

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

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

Перш ніж поширювати новий отриманий блок на інші вузли, валідатори швидко завершать перевірку перших 25 контрольних точок протягом 40 мілісекунд. Якщо перевірка успішна, вона викликає поширення блоку та продовжує перевірку решти контрольних точок.

Повні контрольні точки завершуються шляхом перевірки всіх залишкових контрольних точок. Після перших 25 контрольних точок є 500 контрольних точок перевірки, за якими йдуть ще 500 контрольних точок перевірки, інтервал подвоюється для кожної наступної групи з 500 контрольних точок.

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

Рисунок 4: Процес перевірки хеш-ланцюга

Насіння Ланцюга Хешу

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

Для зменшення ймовірності виникнення таких зсувів хеш-ланцюгів, Arweave синхронізує глобальний хеш-ланцюг, використовуючи токени з історичних блоків через фіксовані інтервали. Це регулярно надає нові насіння для хеш-ланцюга, забезпечуючи синхронізацію хеш-ланцюгів серед різних майнерів з перевіреним блоком.

Інтервал для насінин ланцюга хешів становить кожні 50 * 120 видобутих хешів (50 представляє кількість блоків, а 120 представляє кількість видобутих хешів протягом циклу виробництва блоку 2 хвилини), щоб вибрати новий насіниновий блок. Це означає, що блоки насінин з'являються приблизно кожні ~50 блоків Arweave, але через варіації у часах блоків, блоки насінин можуть з'являтися трохи раніше або пізніше, ніж 50 блоків.

Фігура 5: Метод генерації насіння хеш-ланцюга

Вищевказаний витяг з специфікації версії 2.6 автора показує, що Arweave реалізував низькопотужні, більш децентралізовані механізми для роботи всієї мережі, починаючи з версії 2.6. Візія Сатоші Накамото знаходить практичне втілення в Arweave.

Arweave 2.6: https://2-6-spec.arweave.dev/

Заява:

1. Ця стаття спочатку мала назву «Arweave 2.6, можливо, більше відповідає бажанням Сатоші Накамото», вона відтворена з[PermaDAO]. Усі авторські права належать оригінальному автору [Arweave Оазис]. Якщо у вас є які-небудь зауваження до репринту, будь ласка, зв'яжіться Gate Навчаннякоманда, команда вирішить це якнайшвидше.

2. Увага: Погляди та думки, висловлені в цій статті, відображають лише особисті погляди автора і не становлять жодної інвестиційної поради.

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонене.