Якщо ви слідкували за @SpaceandTimeDB, ви напевно чули про Proof of SQL (наш роман Zk Proof). Тому сьогодні я розповім вам про реальні випадки використання доказу SQL з прикладами, що охоплюють DeFi, оракули, крос-чейн інфраструктуру, надання ліквідності та навіть установи. Спочатку - припустимо, ви хочете запустити токен: $XYZ. Отже, ви підходите до кита і укладаєте угоду... «Агов, якщо ви додасте 1 мільйон доларів в USDT до мого пулу ліквідності на Uniswap, я дам вам 1% від пропозиції $XYZ». Ця угода записана в смарт-контракт, так? Але тепер проблема полягає в тому, що цей контракт має запитати та перевірити, що цей кит дійсно вніс те, що обіцяв, щоб отримати винагороду. Отже, вам потрібен смарт-контракт, який: - підтверджує, що цей кит дійсно додав 1 мільйон доларів USDT. - відстежує гаманець + мітка часу. - Застосовує винагороду в розмірі 1% токена. але цей 1 мільйон доларів USDT насправді живе поза мережею. Prolly на підграфі DEX або API Uniswap. Саме тут ми хочемо додати доказ SQL. Отже, депозит ліквідності кита запитується через SQL, потім він криптографічно перевіряється і, нарешті, вводиться в смарт-контракт з припущеннями нульової довіри. По-друге, підзвітність оператора вузла (скорочення/нагородження). У таких мережах, як @chainlink або будь-який Depin, кілька вузлів виконують завдання (отримують ціни, перевіряють особистість, виконують обчислення тощо). Кожен вузол має бути винагороджений справедливо та відповідно. Якщо вони обманюють або відключаються, їх потрібно скоротити. Але є проблема. Як смарт-контракт дізнається, який вузол виконав яку роботу? Зверніть увагу, що активність оператора відбувається поза ланцюгом (часто зберігається в журналах або базах даних), тому чи не хотіли б ви, як оператор вузла, щоб дані були точними? Якщо вас збираються порізати, ви хочете бути до біса впевнені, що вас ріжуть з реальної причини. знову ж таки, тут на допомогу приходить доказ SQL. за допомогою Proof of SQL мережа може: - Журнали виконання завдань із запитами. - Згенеруйте перевірений доказ продуктивності вузла. - Подавайте його в ланцюжок, щоб автоматизувати логіку винагороди або скорочення. Отже, врешті-решт, якщо вас поріжуть, ви знаєте чому, тому що ви можете побачити криптографічний чек, який доводить, що це було зроблено з реальної причини. коли справа доходить до перевірки крос-чейн забезпечення, нам все ще потрібен доказ SQL. Припустимо, ви створюєте протокол кредитування на базі та Ethereum, де користувачі вносять заставу в обидва ланцюги. Як довести загальний TVL? Як ви відстежуєте заставу користувачів в обох ланцюгах? Крім того, як запобігти подвійному підрахунку або шахрайству? без підтвердження SQL, вам потрібно: - довіряти кастомним API. - покладатися на мостові дані. - Централізуйте серверну частину. :/ але з доведенням SQL ви можете: - запитувати стан кросчейну з даних обох ланцюгів. - довести це криптографічно. - використовувати єдине подання для забезпечення кредитування, ліквідації та відсоткових ставок. Нарешті. Скажімо, ви великий банк Tradfi, який прагне токенізувати свої активи. Ви б хотіли: - запустити РВА. - кредитувати під заставу активів. - довести клієнтам платоспроможність або заставу. Але дані про ваші активи зберігаються в базі даних офчейн. Замість того, щоб скидати конфіденційну інформацію в мережу, ви можете використовувати доказ SQL для запиту вашої внутрішньої бази даних, створення криптографічного підтвердження балансів і підтвердження права власності на актив або забезпечення без розкриття фактичних даних. по суті, ZK + SQL = конфіденційність інституційного рівня + прозорість. Якщо ви створюєте токен за допомогою угод про ліквідність або використовуєте мережу DePIN або оракула, або навіть розгортаєте багатоланцюгове кредитування, вам знадобляться перевірені офчейн-дані. і це те, що дає вам Proof of SQL від @SpaceandTimeDB.