# Space and Time. Представляем: Доказательство SQL™. Перевод на русский язык

By [NFTerraX](https://paragraph.com/@nfterrax-2) · 2022-12-25

---

Используя сочетание стандартных методов и неустанной оптимизации, эксперты по математике и криптографии из Space and Time почти готовы выпустить Proof-of-SQL.

Независимо от того, являетесь ли вы разработчиком на цепочке или бизнес-аналитиком и рок-звездой SQL, слишком много данных хранится вне цепочки и вне хранилища данных. Криптографы обещали, что вы можете безопасно передать запросы к базе данных на недоверенный сервер с проверяемыми вычислениями. Впервые в истории это действительно осуществимо в среде Web3.

Необработанные данные против полезных данных
--------------------------------------------

Ваша компания, ваш любимый блокчейн и ваше приложение ежедневно генерируют терабайты данных, хранящих истории заказов, транзакций и пользовательского контента. Правда в том, что большая часть этих данных вам безразлична!

Подумайте о приборной панели Tableau в сравнении с файлом .csv (или .xlsx, если хотите). В интуитивном, человеческом смысле, приборная панель несет гораздо больше полезной информации. Просто невозможно прочитать 100 000 строк значений, разделенных запятыми, и глубоко понять, что означают эти данные. Именно поэтому существует SQL, и именно поэтому существует множество вакансий бизнес-аналитика. Агрегирование не только облегчает понимание, но и, с точки зрения компьютера, несет меньше информации, чем файл .csv. Если вы объединяете данные в простое визуальное представление, скажем, в круговую диаграмму, то компьютеру не нужно предоставлять вам информацию о каждой отдельной строке. Все это может оставаться в хранилище данных.

Итак, для конечного пользователя проблема заключается в том, что данных много (больше, чем вы можете хранить локально), вы хотите извлечь из них некоторую информацию (гораздо меньше информации, чем исходные данные), и вы несколько ограничены в пропускной способности (количество данных, которые вы можете получить из хранилища). Поэтому просто отправьте круговую диаграмму!

Это хорошо, если ваша компания владеет хранилищем данных, ваши серверы и ваша организация не были взломаны, и нет причин для фальсификации результатов. В условиях Web3 возникает проблема: как узнать, что метафорическая круговая диаграмма правильно построена с использованием правильных данных?

Проверяемые вычисления и необъяснение доказательств нулевого знания
-------------------------------------------------------------------

Оказывается, эта проблема “решается” с [начала 90-х годов](https://link.springer.com/chapter/10.1007/978-3-642-60322-8_22). Теоретически. А может, и не решалась до [2008](https://youtu.be/x8pUxFptfb0?t=395) года. Трудно сказать.

Если вы когда-нибудь читали криптовалютные статьи, вы поймете, что верный способ решить эту проблему — придумать абсолютно безумное техническое решение.  
\- [Мэтью Грин о ZKPs](https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/)

Решение, которое придумали криптографы, — это “делегированные вычисления” или “[проверяемые вычисления](https://www.spaceandtime.io/blog/verifiable-computing-and-commitments)”, и оно основано на теории интерактивных доказательств. Особенно сильно мы опираемся на методы из Zero Knowledge Proofs (ZKPs), которые представляют собой протоколы, позволяющие недоверенному проверяющему убедить проверяемого в истинности утверждения, не передавая при этом [никакой дополнительной информации](https://www.youtube.com/watch?v=fOGdb1CTu5c). Нулевое знание отлично подходит для других криптографических протоколов, таких как цифровые подписи. Proof-of-SQL не является ZKP. Просто в этом нет необходимости. Мы не пытаемся спрятать данные в хранилище данных, мы просто хотим избежать необходимости хранить их локально.

На самом деле, исследования в области интерактивных доказательств породили [множество протоколов](https://nakamoto.com/cambrian-explosion-of-crypto-proofs/), так что мы можем выбирать, какие свойства нам нужны, и оптимизировать для получения наиболее производительной системы для защищенных от взлома SQL-запросов.

Арифметизация? Скорее (ск)ари математическое уклонение!
-------------------------------------------------------

Я бы с удовольствием рассказал, как мы переходим от SQL-запроса к криптографическому обещанию, но мне сказали не вдаваться в такие подробности. Короткий ответ: мы превращаем это в математику. Я не имею в виду “в Пространстве и Времени мы превращаем это в математику”. Я имею в виду, что никто не знает, как сделать эти криптографические гарантии для программ без некоторого промежуточного представления, которое гораздо больше похоже на математику, чем на что-либо другое. Этот шаг называется [арифметизацией](https://medium.com/starkware/arithmetization-i-15c046390862), и он имеет решающее значение для эффективности Proof-of-SQL.

Арифметизация может действительно сделать или сломать доказательство с нулевым знанием. Я уже упоминал цифровые подписи, и в течение нескольких десятилетий они были единственным типом криптографического доказательства, который действительно использовался в реальном мире. Подписи великолепны и практичны, потому что их арифметизация естественным образом работает с той же математикой, что и в других видах криптографии с открытым ключом. Я не говорю, что математика проста, но независимо от того, основана ли она на [модульной арифметике](https://www.geeksforgeeks.org/rsa-and-digital-signatures/) или [эллиптических кривых](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm), по крайней мере, нет никаких затрат на перевод. В любом другом случае (скажем, при переводе смарт-контракта в доказуемую форму) много накладных расходов возникает только на этапе арифметизации.

Вот один крайний пример неэффективной арифметизации: раньше криптографы брали бит, который является абсолютно наименьшим количеством данных, достаточным для хранения только “0” или “1”, “да” или “нет”, или того, включен или выключен выключатель, и представляли его в виде элемента поля, используя 256 бит. Подумайте об этом; если бы у вас было что-то, что хранилось в коробке, в 256 раз большей, чем вы сами, вы бы захотели выбросить эту коробку, потому что она занимает слишком много места в вашем доме.

Мораль этой истории в том, что выбор промежуточного представления является наиболее важным выбором при проектировании для снижения накладных расходов. Чем ближе ваша математическая модель к самому вычислению, тем меньше “стоимость перевода”, возникающая на этапе арифметизации. Поэтому, ориентируясь конкретно на SQL, мы можем обрабатывать реальные сценарии использования, размеры которых немыслимы для современных SNARG общего назначения. Запросы к базам данных (а точнее, реляционная алгебра, которая лежит в их основе) имеют [хорошую характеристику](https://en.wikipedia.org/wiki/L_\(complexity\)#Complete_problems_and_logical_characterization), которая делает их очень удобными для криптографических доказательств, но “универсальные” SNARK просто не приспособлены для использования этого преимущества.

Нет секретного соуса (о котором я бы вам рассказал)
---------------------------------------------------

Как бы ни было весело публиковать наши коммерческие секреты в блоге… у нас их не так много. Space and Time не занимается грандиозными обещаниями, которые мы не можем подтвердить. Хотя защищенные от взлома запросы к базе данных — это фантастическое обещание, мы придумали естественное решение в Proof-of-SQL, потому что мы знаем:

*   Вам не нужны тонны данных, вам нужна осмысленная аналитика, проверяемая на аутсорсинге.
    
*   Криптографические инновации приблизили эту цель на расстояние удара.
    
*   Арифметизация с учетом специфики домена выводит нас на финишную прямую
    

Благодаря сочетанию стандартных методов и неустанной оптимизации, эксперты по математике и криптографии из Space and Time почти готовы выпустить Proof-of-SQL, сделав различие между данными на цепочке и вне цепочки практически неважным.

> **Оригинал:** [https://www.spaceandtime.io/blog/proof-of-sql](https://www.spaceandtime.io/blog/proof-of-sql)

Официальные ссылки:
-------------------

[**Website**](http://www.spaceandtime.io/) | [**Twitter**](https://twitter.com/SpaceandTimeDB) | [**Linkedin**](https://www.linkedin.com/company/space-and-time-labs/) | [**Discord**](https://discord.gg/exN9FjeJhq) | [**Telegram**](https://t.me/spaceandtimelabs) | [**Youtube**](https://www.youtube.com/channel/UCXJyE7ahmqCH11aO7L76PBA) | [**Instagram**](https://instagram.com/SpaceandTimeDB) | [**Reddit**](https://www.reddit.com/r/spaceandtimeDB/) | [**CrunchBase**](https://www.crunchbase.com/organization/space-and-time)

---

*Originally published on [NFTerraX](https://paragraph.com/@nfterrax-2/space-and-time-sql-2)*
