Проект Aleo Блокчейн: забезпечення конфіденційності та масштабованості за допомогою технології zk-SNARKs

Aleo є проектом Блокчейн, що зосереджується на захисті конфіденційності, використовуючи технологію zk-SNARKs (ZKP) для підвищення конфіденційності та масштабованості. Основна ідея Aleo полягає в тому, щоб дозволити користувачам проводити автентифікацію та обробку даних без розкриття особистих даних.

Ця стаття представляє огляд проекту Aleo та останні досягнення, а також детально аналізує оновлення алгоритму puzzle, яке викликало великий інтерес на ринку.

Огляд нових алгоритмів

Мережа Aleo випадковим чином генерує один ZK-контур щогодини. Майнерам потрібно протягом цієї години спробувати різні nonce як вхідні дані для контуру, обчислити witness(, тобто всі змінні в контурі, цей процес також називається synthesize), знайти Merkle root для witness, а потім визначити, чи відповідає це вимогам до складності майнінгу. Через випадковість контуру, цей алгоритм майнінгу не є дружнім до GPU і стикається з великими викликами в обчислювальному прискоренні.

Фінансова ситуація

Aleo завершила раунд фінансування серії A на 28 мільйонів доларів, що був очолений a16z, у 2021 році, а в 2024 році завершила раунд фінансування серії B на 200 мільйонів доларів. Інвестори раунду B включають Kora Management, SoftBank Vision Fund 2, Tiger Global, Sea Capital, Slow Ventures та Samsung Next. Цей раунд фінансування підніс оцінку Aleo до 1,45 мільярда доларів.

Огляд проекту

Приватність

Основою Aleo є технологія zk-SNARKs (ZKPs), яка дозволяє виконувати транзакції та смарт-контракти з захистом приватності. Деталі транзакцій користувачів, такі як відправник та сума транзакції, за замовчуванням приховані. Цей дизайн не лише захищає приватність користувачів, але й дозволяє за необхідності здійснювати вибіркове розкриття, що дуже підходить для розвитку DeFi-додатків. Основні компоненти включають:

1. Leo мова програмування: адаптована на основі Rust, спеціально призначена для розробки zk-SNARKs додатків (ZKApps), зменшуючи вимоги до знань криптографії для розробників.

2. snarkVM та snarkOS: snarkVM дозволяє виконувати обчислення поза ланцюгом, а на ланцюзі лише перевіряти результати обчислень, що підвищує ефективність. snarkOS забезпечує безпеку даних і обчислень, а також дозволяє виконання функцій без дозволу.

3. zkCloud: надає безпечне, приватне середовище для обчислень поза блокчейном, підтримує програмну взаємодію між користувачами, організаціями та DAO.

Aleo також надає інтегроване середовище розробки (IDE) та набір інструментів для розробки програмного забезпечення (SDK), що підтримує розробників у швидкому написанні та публікації застосунків. Розробники можуть розгортати застосунки в реєстрі програм Aleo, не покладаючись на третіх осіб, що знижує ризики платформи.

Масштабованість

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

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

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

1. Блок швидка остаточність: AleoBFT забезпечує підтвердження кожного блоку відразу після його створення, підвищуючи стабільність вузлів та користувацький досвід.

2. Децентралізоване забезпечення: шляхом відокремлення виробництва блоків від генерації coinbase, валідатори відповідають за створення блоків, а доказники виконують обчислення доказів, запобігаючи монополізації мережі небагатьма сутностями.

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

Aleo дозволяє розробникам створювати програми, які не підлягають обмеженням gas, тому вони особливо підходять для таких застосувань, як машинне навчання, які потребують тривалого виконання.

Поточний прогрес

Aleo розпочне тестову мережу з винагородами 1 липня, ось деяка важлива остання інформація:

1. Голосування за ARC-100 пройшло: пропозиція ARC-100( "Найкращі практики дотримання для розробників і операторів Aleo", що стосується дотримання, блокування коштів на мережі Aleo та затримок зарахування тощо, голосування ) вже закінчилося і було схвалено. Команда проводить остаточні налаштування.

2. Програма стимулювання валідаторів: програма розпочнеться 1 липня з метою перевірки нової механіки puzzle. Програма триватиме до 15 липня, протягом якого буде розподілено 1 мільйон балів Aleo як винагороду. Відсоток балів, отриманих вузлом, визначатиме його частку винагороди, кожен валідатор повинен заробити щонайменше 100 токенів, щоб отримати винагороду. Конкретні деталі ще не узгоджені.

3. Початкова пропозиція та обіг: Початкова кількість становить 1,5 мільярда токенів, початкова циркуляційна пропозиція становить близько 10%( ще не остаточно визначено). Ці токени в основному отримані з завдання Coinbase(7500 тисяч), які будуть розподілені протягом перших шести місяців, а також включають винагороди за стейкінг, роботу валідаторів та валідаційних вузлів.

4. Тестова мережа Бета скидання: це останнє скидання мережі, після завершення якого не будуть додані нові функції, мережа буде схожа на основну мережу. Скидання необхідне для додавання ARC-41 та нової функції головоломки.

5. Замороження коду: Замороження коду було завершено тиждень тому.

6. План розширення верифікаційних вузлів: початкова кількість верифікаційних вузлів становить 15, мета - збільшити їх до 50 протягом року, а в кінцевому підсумку до 500. Для того, щоб стати делегатом, потрібно 10 000 токенів, для того, щоб стати верифікатором, потрібно 10 000 000 токенів, ці суми поступово зменшуватимуться з часом.

Інтерпретація оновлення алгоритму

Aleo нещодавно оголосила про новини останньої тестової мережі, одночасно оновивши останню версію алгоритму puzzle. Новий алгоритм більше не зосереджується на генерації результату zk proof, видалив MSM і NTT(, які є обчислювальними модулями, що широко використовуються для генерації proof в zk. Раніше учасники тестової мережі оптимізували ефективність цього алгоритму для підвищення прибутковості видобутку ), зосереджуючись на генерації проміжних даних witness перед створенням proof. Нижче наведено короткий опис останнього алгоритму.

Процес консенсусу

На рівні консенсусного протоколу процес, в якому prover і validator відповідно відповідають за отримання обчислювального результату solution та видобуток блоку й агрегацію рішення. Процес виглядає так:

1. Prover обчислює puzzle, створює рішення та транслює їх у мережу.

2. Агрегація транзакцій валідатора та рішення для наступного нового Блоку, гарантувати, що кількість рішень не перевищує обмеження консенсусу (MAX_SOLUTIONS)

3. Легітимність рішення потрібно перевірити, щоб його epoch_hash відповідав latest_epoch_hash, що підтримується валідатором, його обчислений proof_target відповідав latest_proof_target, що підтримується валідаторами в мережі, а також кількість рішень, що містяться в цьому блоці, була меншою за обмеження консенсусу.

4. Дійсне рішення може отримати нагороду за консенсус

Синтез Пазл

Остання версія алгоритму має назву Synthesis Puzzle, її суть полягає в тому, що для кожного epoch фіксується спільна EpochProgram, шляхом побудови R1CS доказового кола для вхідних даних та EpochProgram, створюється відповідне R1CS призначення (, яке всі згадують як witness ) і використовується як листовий вузол Меркле-дерева. Після обчислення всіх листових вузлів генерується корінь Меркле і перетворюється на proof_target рішення. Детальний процес і специфікації побудови Synthesis Puzzle наведені нижче:

1. Кожне обчислення puzzle називається nonce, воно складається з адреси, що отримує винагороду за майнінг, epoch_hash та випадкового числа counter, кожного разу, коли потрібно обчислити нове рішення, nonce можна отримати шляхом оновлення counter.

2. У кожному епосі всі prover у мережі повинні обчислити один і той же EpochProgram, який вибирається з набору інструкцій на основі випадкових чисел, що генеруються з поточного epoch_hash, логіка вибірки така:

   • Інструкційний набір є фіксованим, кожна інструкція (instruction) містить одну або декілька обчислювальних операцій, кожна інструкція має попередньо визначену вагу та кількість операцій.
   • Під час вибірки випадкове число генерується на основі поточного epoch_hash, це випадкове число використовується для отримання інструкцій з набору інструкцій у поєднанні з вагою та їх послідовного розташування, вибірка зупиняється після накопичення кількості операцій до 97.
   • Об'єднати всі команди в EpochProgram

3. Використання nonce як насіння випадкових чисел для генерації вхідних даних EpochProgram

4. Агрегуйте R1CS та вхідні дані, відповідні EpochProgram, для виконання обчислень призначення witness(R1CS).

5. Обчисливши всі свідчення, ці свідчення будуть перетворені на відповідну послідовність листових вузлів меркл-дерева, меркл-дерево є K-арним меркл-деревом з глибиною 8.

6. Обчисліть merkle root і перетворіть його на proof_target рішення, визначте, чи відповідає він поточному epoch latest_proof_target. Якщо відповідає, то обчислення успішне, подайте reward address, epoch_hash та counter, які потрібні для побудови вхідних даних, як рішення та транслюйте.

7. В одному і тому ж epoch можна кілька разів виконати обчислення рішення, оновлюючи вхідні дані EpochProgram шляхом ітерації лічильника.

Зміни та впливи майнінгу

Після цього оновлення puzzle перетворився з генерування proof на генерування witness, логіка обчислення всіх рішень протягом кожного epoch залишається незмінною, але логіка обчислення між різними epoch має суттєві відмінності.

З попереднього тестового мережі ми можемо виявити багато методів оптимізації, які зосереджені на використанні GPU для оптимізації обчислень MSM та NTT на етапі генерації proof, що підвищує ефективність видобутку. Це оновлення повністю відмовляється від цієї частини обчислень; одночасно, оскільки процес генерації witness виникає внаслідок виконання програми, що змінюється з епохами, деякі інструкції будуть мати часткову залежність від послідовного виконання, тому реалізація паралелізації має значні виклики.