zkDocs: Обмін інформацією з нульовим знанням PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

zkDocs: Обмін інформацією без знань

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

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

Тут ми демонструємо, як кілька криптографічних примітивів, розроблених і популяризованих рухом web3, можуть покращити робочі процеси перевірки інформації, зберігаючи при цьому конфіденційність і децентралізацію, за допомогою нашого нещодавно випущеного сховище zkDocs. Це інструмент для створення «документів із нульовим знанням», який дозволяє різним сторонам у певному робочому процесі обмінюватися інформацією та перевіряти її, а також гарантувати, що вона відповідає певним критеріям — без непотрібного її розкриття.

[Вбудоване вміст]

Але спочатку: як це працює, основні механізми тощо

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

  • Верифікатор: Адміністратор або творець схеми zkDoc. У нашому прикладі верифікатором є іпотечний кредитор.
  • Відправник: Особа або особи, які бажають отримати перевірку даних за допомогою схеми. Це позичальник або потенційний покупець житла.
  • засвідчувач: Довірена особа чи установа, яка може засвідчити правдивість одного чи кількох полів заявника. Це може бути роботодавець або оцінювач житла.

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

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

zkDocs також дозволяє заявнику ділитися лише відповідною інформацією з кожним засвідчувачем. Роботодавець може лише підтвердити заробітну плату та статус зайнятості заявника, наприклад, не бачачи непотрібних фінансових деталей. 

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

Слід звернути увагу на два основні механізми: атестації та докази нульових знань.

Використання блокчейнів для атестації

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

Однак одним із недоліків публікації атестацій у блокчейні є те, що базові значення є загальнодоступними. zkDocs вирішує це шляхом трансляції криптографічні зобов'язання до значень замість значень відкритого тексту. Ці зобов’язання залишаються загальнодоступними, але їх основні цінності не видно.

Що таке криптографічне зобов’язання?

Криптографічне зобов’язання дозволяє одній стороні генерувати зобов’язання щодо деяких приватних даних. Пізніше комітер може відкрити зобов'язання, щоб показати зафіксовані дані. 

Схеми зобов’язань мають бути (1) прихованими, тобто зобов’язання нічого не розкриває про дані, і (2) обов’язковими, тобто комітер не може знайти зобов’язання, яке можна відкрити двома різними способами. 

Найпростіша схема зобов’язань побудована з криптографічної хеш-функції — наприклад, Посейдон хеш. Щоб зафіксувати деякі дані, комітер обчислює: зобов'язання ← посейдон(дані, нунцій), де нунцій це випадковий 512-бітний рядок. Щоб відкрити зобов'язання пізніше, комітент відкриває дані і нунцій. Будь-хто може переконатися, що зобов'язання було відкрито правильно.

Перевірка особистих даних за допомогою доказів нульового знання

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

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

Зокрема, субмітер генерує доказ нульового знання того, що йому відомий масив (значення, нунцій) такі пари, що:

  • poseidon(value[i], nonce[i]) == prior_commitment[i] та
  • value[0], …, value[n] задовольняють обмеження

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

Щоб продемонструвати, розглянемо два коротких приклади.

Приклад: заява на іпотеку

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

Іпотечний кредитор (у цьому випадку верифікатор) створить схему для zkDoc таким чином:


{
  "fields": [
    {
      "field_name": "salary"
    },
    {
      "field_name": "401k_income"
    },
    {
      "field_name": "bank_account_balance"
    },
    {
      "field_name": "property_value"
    },
    {
      "field_name": "loan_value"
    }
  ],
  "constraints": [
    {
      "fieldA": "bank_account_balance",
      "fieldB": "property_value",
      "op": "ADD",
      "constraint": "GT",
      "fieldCompare": "loan_value"
    },
    {
      "fieldA": "salary",
      "fieldB": "401k_income",
      "op": "ADD",
      "constraint": "GT",
      "constant": 65000
    }
  ],
  "trusted_institutions": [
    {
      "human_name": "Employer",
      "address": "0xabcd..."
    },
    {
      "human_name": "Home Appraiser",
      "address": "0xabcd..."
    },
    {
      "human_name": "401k Provider",
      "address": "0xabcd..."
    },
    {
      "human_name": "Checking Account Provider",
      "address": "0xabcd..."
    },
    {
      "human_name": "Creditor",
      "address": "0xabcd..."
    }
  ]
}

Спочатку схема визначає кілька полів, які цікавлять позикодавця: зарплата, дохід 401(k), баланс поточного рахунку, вартість майна та вартість позики. 

Тоді два обмеження на ці поля: 

  1. Сума вартості майна та залишку на банківському рахунку перевищує вартість кредиту
  2. Сума доходу та зарплати 401(k) перевищує 65,000 XNUMX доларів США на рік

І, нарешті, п’ять установ, яким він довіряє підтвердити цю інформацію:

  1. Роботодавець
  2. Оцінювач житла
  3. 401(k) провайдер
  4. Постачальник поточного рахунку
  5. Кредитор

Щоб подати заявку на отримання іпотеки, заявник заповнює поля, перелічені в розділі «поля», використовуючи інтерфейс користувача zkDocs і публікує криптографічне зобов’язання в ланцюжку для кожного. Потім заявник надсилає відповідні поля відкритого тексту разом із одноразовими номерами для кожного зобов’язання, до кожного з атестуючих закладів (з набору, перерахованого нижче trusted_institutions). Інтерфейс користувача zkDocs робить це за допомогою гіперпосилань.

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

Приклад: кредити MakerDAO RWA

MakerDAO — це протокол кредитування, який на сьогоднішній день випущено 6 мільярдів доларів кредитів деномінований у DAI (токен, прив’язаний до долара США). Підрозділ Real World Assets (RWA) компанії Maker працює над наданням позик, деномінованих у DAI, кредиторам, які займаються нинішньою ланкою, що дає змогу DAI напряму стимулювати економічне зростання в реальному світі. Але Maker — це DAO, маркер управління яким належить приблизно 78,000 XNUMX унікальних гаманців, кожен з яких має право брати участь у процесі управління та керувати майбутнім протоколу. 

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


{
  "fields": [
    {
      "field_name": "custodian_name"
    }, 
    {
      "field_name""total_loan"
    },
    {
      "field_name": "total_collateral_value"
    },
    {
      "field_name": "amount_repaid"
    }
  ],
  "constraints": [
    {
      "fieldA": "total_loan",
      "fieldB": "amount_repaid",
      "op": "SUB",
      "constraint": "LT",
      "fieldCompare": "total_collateral_value"
    }
  ],
  "trusted_institutions": [
    {
      "address": "0xabcd…",
      "human_name": "Bob the Custodian"
    }
  ]
}

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

***
zkDocs, як зараз реалізовано, використовує:

  • Підписані транзакції (або будь-який EVM-сумісний ланцюжок) для перевірки автентичності атестацій
  • Загальнодоступний блоковий простір для зберігання як зобов’язань, так і атестацій
  • Розумні контракти для перевірки доказів з нульовим знанням 

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

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

Часова мітка:

Більше від Андреессен Горовиц