Нещодавно iExec представив нові інструменти розробника для вирішення проблеми використання «маркетингу, що покращує конфіденційність». Такими інструментами є iExec DataProtector і iExec Web3Mail. Ці інструменти розробника, які існують у вигляді простих у використанні пакетів коду npm, спрямовані на революцію в тому, як DApps обробляють конфіденційність даних і зв’язок. У цій статті ми докладно розглянемо технічні функції DataProtector і Web3Mail.

iExec DataProtector

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

Цей інструмент є ефективним рішенням для обробки даних; він об’єднує та спрощує такі функції набору даних iExec, як шифрування даних і керування правами доступу. Крім того, DataProtector полегшує пошук усіх захищених даних, пов’язаних із певним власником або певною схемою даних (див. нижче приклад схеми даних). Він також надає користувачеві можливість відкликати одне або всі права доступу до даних. Іншими словами, власники даних мають можливість динамічно керувати та контролювати дозволи доступу, що забезпечує надійну безпеку та конфіденційність їхніх даних за допомогою зручного інструменту.

В екосистемі iExec набір даних — це невзаємозамінний токен (NFT), який використовується як механізм керування конфіденційними даними. У iExec Marketplace постачальники наборів даних створюють і підписують «замовлення набору даних», які визначають керування набором даних, напр. який Dapp може використовувати набір даних. У DataProtector власники даних визначають правила доступу вищого рівня, які автоматично перетворюються на порядок наборів даних.

DataProtector можна легко інтегрувати в будь-який програмний проект (швидкий старт), щоб зробити захищені дані безперешкодно доступними для авторизованих додатків Confidential Computing.

DataProtector покладається на:

1/ смарт-контракт DataProtector, який взаємодіє зі смарт-контрактом DatasetRegistry для створення набору даних;

2/ підграф DataProtector, сервер поза мережею, який постійно спостерігає за подіями в блокчейні, а потім зберігає, індексує та отримує дані, захищені DataProtector, і використовує такі компоненти протоколу iExec:

  • Смарт-контракт DatasetRegistry для створення/карбування відповідного набору даних, пов’язаного із захищеними даними

  • смарт-контракт PoCo для керування правами доступу

  • iExec Marketplace для обміну замовленнями

  • Служба секретного керування (SMS) для зберігання секретів користувачів

Шість функцій DataProtector

1/ ProtectData шифрує дані користувачів і записує право власності на смарт-контракт.

Щоб захистити свої дані, користувач викликає функцію protectData, надаючи дані даних як вхідні дані. За бажанням користувач також може вказати ім’я для даних, які будуть публічною інформацією та залишатимуться незашифрованими. Якщо ім’я не вказано, воно призначається як «Без назви».

Ось приклад об’єкта даних:

дані:
{
електронна адреса: 'example@gmail.com',
SMTP-сервер: {
порт: 5000,
smtp_server: 'smtp.gmail.com'
}
}

У цьому прикладі об’єкт даних складається з двох ключів: електронної пошти та SMTP-сервера. Значення електронної пошти – example@gmail.com. Значення SMTPserver містить дві інші пари ключ/значення: порт зі значенням 5000 і smtp_server зі значенням smtp.gmail.com.

Потім функція protectData виконує такі дії:

  1. Витягніть схему даних, тобто інший ключ і тип кожного значення. Ось відповідна схема даних попереднього прикладу даних:

dataSchema:
{
"email": "рядок",
"SMTP-сервер": {
"порт": "цілі",
"smtp_server": "рядок"
}
}

2. Створіть архів даних, який буде відображатися як папка. У цій папці створюється файл для кожного ключа. Тип кожного файлу відповідає типу відповідного ключа, і файл містить відповідне значення, указане в даних. Можна мати піддані, які відповідають підпарам ключ/значення ключа. Цей ключ створюється як папка, у якій створюється файл для кожної пари підключ/значення. Глобальна папка запакована в архів.

Ось відповідний архів попереднього прикладу даних:

Приклад: права частина для включення

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

3. Згенеруйте ключ шифрування та зашифруйте архів. У цьому шифруванні використовується стандартна схема шифрування AES-256-CBC. Потім зашифрований архів надсилається в загальнодоступне сховище IPFS.

4. Надішліть у смарт-контракт DataProtector схему даних разом із класичними аргументами створення наборів даних:

  • Смарт-контракт DataProtector викликає смарт-контракт DatasetRegistry для створення відповідного набору даних і транслює схему даних у події блокчейну.

  • Підграф DataProtector спостерігає за цією подією та індексує захищені дані.

5. Вставте секретний ключ шифрування в SMS.

6. Поверніть користувачеві значення protectedData та метаданих.

2/ grantAccess, який дозволяє програмі використовувати дані користувачів, не розкриваючи самих даних.

grantAccess diagram iExec

Власник даних використовує функцію grantAccess, щоб авторизувати програму та запитувача на доступ до його або її захищених даних. Ця функція приймає як вхідні дані protectedData, authorizedApp і authorizedUser, які є адресами захищених даних, програми та користувача відповідно. Потім функція grantAccess виконує такі дії:

  1. Створіть порядок набору даних, щоб установити правила керування, тобто права доступу для authorizedApp і authorizedUser, підписані власником набору даних.

  2. Опублікуйте порядок набору даних на iExec Marketplace.

  3. Повернути користувачеві порядок набору даних.

3/ revokeAllAccessObservable, який скасовує доступ усіх програм до певних захищених даних.

Функція revokeAllAccessObservable викликається власником даних зі значенням protectedData та, за бажанням, фільтром authorizedApp та/або фільтром authorizedUser. Потім функція revokeAllAccessObservable виконує такі дії:

  1. Надсилайте запит datasetorders до ринку та, якщо надано, відповідає фільтрам.

  2. Для кожного datasetorder він відкликає datasetorder за допомогою виклику смарт-контракту PoCo, який видає подію цього відкликання. API Marketplace спостерігає за цією подією та очищає відповідне замовлення.

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

4/ revokeOneAccess, який скасовує доступ програми до певного захищеного набору даних.

Функція revokeOneAccess подібна до функції revokeAllAccessObservable, за винятком того, що відкликання здійснюється для одного доступу. Власник даних викликає revokeOneAccess із grantedAccess як вхідні дані, щоб ініціювати відкликання цього доступу. Значення grantedAccess можна отримати з функції fetchGrantedAccess. Потім revokeOneAccess виконує такі дії:

  1. Надішліть запит на відкликання відповідного набору даних для смарт-контракту PoCo, який видає подію цього відкликання. API Marketplace спостерігає за цією подією та очищає відповідне замовлення.

  2. Поверніть порядок набору даних і транзакцію, підписану власником, який скасовує доступ.

5/ fetchProtectedData, який отримує зашифровані дані, захищені DataProtector.

Користувач викликає функцію fetchProtectedData із необов’язковим фільтром власника (для отримання лише зашифрованих даних конкретного користувача) та/або фільтром dataSchema (для отримання зашифрованих даних за допомогою певної схеми). Потім функція fetchProtectedData виконує такі дії:

  1. Запитувати захищені дані в підграф DataProtector, необов’язково зіставляючи фільтри.

  2. Повернути користувачеві масив запитуваних захищених даних, тобто ім’я, адресу, власника та схему кожного захищеного даних, необов’язково відповідаючи фільтрам.

6/ fetchGrantedAccess, який надає список доступів, наданих до певних захищених даних.

Функція fetchGrantedAccess має механізм, подібний до функції fetchProtectedData, за винятком того, що запит надається для наданого доступу до певних захищених даних. Цей запит працює наступним чином:

  1. Користувач викликає fetchGrantedAccess із protectedData як входом. За бажанням користувач може запитувати лише авторизовані програми та/або авторизований запитувач, вказавши фільтри authorizedApp і authorizedUser відповідно.

  2. fetchGrantedAccess запитує порядок набору даних, який відповідає фільтрам, до API Marketplace і повертає масив усіх наданих доступів.

Приклад використання: Web3Mail

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

Web3Mail покладається на DataProtector для захисту електронних адрес і взаємодії з протоколом iExec, sendEmail DApp і службою mailjet для надсилання електронних листів.

У iExec Marketplace постачальники програм створюють і підписують «apporders», які визначають керування програмою, напр. плата за кожне виконання DApp. У Web3Mail DApp sendEmail уже розгорнуто, а відповідний додаток підписаний і опублікований на iExec Marketplace. Додаток sendEmail DApp приймає тему та вміст електронного листа як секрети запитувача та надсилає електронний лист на захищену електронну адресу.

У протоколі iExec секрети запитувача є параметрами, які надаються лише авторизованим програмам усередині анклавів і ніколи їх не залишають. У Web3Mail лише програма sendEmail DApp може отримати доступ до теми та вмісту електронних листів.

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

Для кожного захищеного електронного листа було створено набір даних, а відповідний порядок набору даних було підписано та опубліковано в iExec Marketplace та проіндексовано Graph.

Web3Mail складається з двох функцій:

  • fetchMyContacts, який повертає список облікових записів Ethereum, власники яких дозволили їм надсилати електронні листи. Користувач викликає функцію fetchMyContacts, яка виконує такі дії:

  1. Надішліть запит до API Marketplace, щоб відновити список замовлень набору даних, для яких власники надали користувачеві дозвіл на доступ і використання свого захищеного набору даних.

  2. Запитувати відповідні захищені набори даних до Graph.

  3. Перевірте, чи містить кожен набір даних поле електронної пошти, переконавшись, що схема кожного захищеного набору даних збігається з «email:string».

  4. Повернути користувачеві список дійсних контактів, включаючи захищений набір даних і адреси власників.

  • sendEmail, який надсилає електронний лист користувачеві, знаючи лише обліковий запис Ethereum

Користувач викликає функцію sendEmail, щоб надіслати електронний лист авторизованому власнику облікового запису Ethereum, який можна отримати за допомогою функції fetchMyContacts. Користувач вказує тему електронної пошти emailSubject, вміст електронної пошти emailContent і захищену електронну адресу protectedData.

Функція sendEmail створює та підписує замовлення під назвою «requestorder» для запиту на виконання програми sendEmail DApp. Тому процес цієї функції схожий на створення запиту на завдання в протоколі iExec.

В екосистемі iExec завдання — це випадок, коли потрібна обчислювальна потужність. Завдання — це виконання угоди між datasetorder, apporder, requestorder і workerpoolorder, що вказує, які працівники доступні для певної категорії завдань. У Web3Mail завдання — це виконання програми sendEmail DApp із захищеною електронною поштою як набором даних, темою електронної пошти та вмістом електронної пошти як секретами запитувача.

sendEmail обробляє такі кроки:

  1. Надішліть SMS-запит, щоб перевірити наявність маркера зберігання. Цей маркер використовується як маркер автентифікації для працівника для завантаження результату завдання. Це гарантує, що лише авторизований працівник зможе подати результат завдання.

  2. Надішліть запит на відповідний захищений набір даних до Graph і перевірте, чи кожен набір даних містить поле електронної пошти.

  3. Запит до API Marketplace: порядок набору даних захищеної електронної пошти з адресою protectedData, додаток sendEmail DApp, робочий пулorder

  4. Надішліть тему електронної пошти та вміст електронної пошти як секрети запитувача (додаткову інформацію див. у технічній документації iExec).

  5. Створіть і підпишіть запит на виконання запиту DApp sendEmail із emailSubject і emailContent як секретами запитувача. У запиті замовлення користувач може вказати ціну, яку він готовий заплатити за виконання завдання.

  6. Повідомте смарт-контракт PoCo про відповідність замовлень між apporder, datasetorder, workerpoolorder і requesterorder. Потім смарт-контракт PoCo: перевіряє та підтверджує збіг, видає збіг замовлень і сповіщення планувальнику робочого пулу, повертає dealid

  7. Запит на обчислення відповідного завдання угоди для смарт-контракту PoCo. Планувальник, який уже спостерігав за збігом замовлень і сповіщень від смарт-контракту PoCo, ініціює завдання, яке запускає виконання sendEmail DApp.

  8. Повернути taskid користувачеві.

Обмеження цих інструментів

DataProtector і Web3Mail використовують конфіденційні обчислення (CC), розроблені iExec. SMS, що використовується в iExec CC, є централізованим компонентом, у якому користувачі надсилають свої секрети, напр. секретний ключ для шифрування даних. Коли секрет отримано, SMS створює захищений сеанс у CAS (служба конфігурації та атестації), надсилає секрет і надає додатку, пов’язаному з запитом, доступ до нього. Однак через централізований характер SMS існує потенційна єдина точка збою. Якщо CAS або SMS оновлюються або не працюють, існує ризик втрати збережених секретів. Щоб вирішити цю проблему, iExec активно працює над децентралізацією SMS, тим самим пом’якшуючи вищезгадану проблему та підвищуючи загальну стійкість системи.

Важливо зазначити, що Web3Mail використовує служби Mailjet, використовуючи проміжну адресу електронної пошти для полегшення надсилання електронних листів. Рівень довіри до Web3Mail напряму пов’язаний із довірою як до служби mailjet, так і до iExec, який керує нею та має можливість доступу до адрес електронної пошти та вмісту електронної пошти.

Дякуємо за читання!

💬 Якщо ви хочете запитати щось про ці інструменти або дізнатися про можливості фінансування, не соромтеся зв’язатися з командою iExec на нашому офіційному сервері Discord.

📚Почніть роботу з цими інструментами, перегляньте документацію iExec

$RLC #iExec #AI #Web3 #blockchain #Dapps