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

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

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

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

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

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

Оказывается, эта проблема “решается” с начала 90-х годов. Теоретически. А может, и не решалась до 2008 года. Трудно сказать.

Если вы когда-нибудь читали криптовалютные статьи, вы поймете, что верный способ решить эту проблему — придумать абсолютно безумное техническое решение.
- Мэтью Грин о ZKPs

Решение, которое придумали криптографы, — это “делегированные вычисления” или “проверяемые вычисления”, и оно основано на теории интерактивных доказательств. Особенно сильно мы опираемся на методы из Zero Knowledge Proofs (ZKPs), которые представляют собой протоколы, позволяющие недоверенному проверяющему убедить проверяемого в истинности утверждения, не передавая при этом никакой дополнительной информации. Нулевое знание отлично подходит для других криптографических протоколов, таких как цифровые подписи. Proof-of-SQL не является ZKP. Просто в этом нет необходимости. Мы не пытаемся спрятать данные в хранилище данных, мы просто хотим избежать необходимости хранить их локально.

На самом деле, исследования в области интерактивных доказательств породили множество протоколов, так что мы можем выбирать, какие свойства нам нужны, и оптимизировать для получения наиболее производительной системы для защищенных от взлома SQL-запросов.

Я бы с удовольствием рассказал, как мы переходим от SQL-запроса к криптографическому обещанию, но мне сказали не вдаваться в такие подробности. Короткий ответ: мы превращаем это в математику. Я не имею в виду “в Пространстве и Времени мы превращаем это в математику”. Я имею в виду, что никто не знает, как сделать эти криптографические гарантии для программ без некоторого промежуточного представления, которое гораздо больше похоже на математику, чем на что-либо другое. Этот шаг называется арифметизацией, и он имеет решающее значение для эффективности Proof-of-SQL.

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

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

Мораль этой истории в том, что выбор промежуточного представления является наиболее важным выбором при проектировании для снижения накладных расходов. Чем ближе ваша математическая модель к самому вычислению, тем меньше “стоимость перевода”, возникающая на этапе арифметизации. Поэтому, ориентируясь конкретно на SQL, мы можем обрабатывать реальные сценарии использования, размеры которых немыслимы для современных SNARG общего назначения. Запросы к базам данных (а точнее, реляционная алгебра, которая лежит в их основе) имеют хорошую характеристику, которая делает их очень удобными для криптографических доказательств, но “универсальные” SNARK просто не приспособлены для использования этого преимущества.

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

• Вам не нужны тонны данных, вам нужна осмысленная аналитика, проверяемая на аутсорсинге.

• Криптографические инновации приблизили эту цель на расстояние удара.

• Арифметизация с учетом специфики домена выводит нас на финишную прямую

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

Оригинал: https://www.spaceandtime.io/blog/proof-of-sql

Website | Twitter | Linkedin | Discord | Telegram | Youtube | Instagram | Reddit | CrunchBase

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

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

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

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

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

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

Оказывается, эта проблема “решается” с начала 90-х годов. Теоретически. А может, и не решалась до 2008 года. Трудно сказать.

Если вы когда-нибудь читали криптовалютные статьи, вы поймете, что верный способ решить эту проблему — придумать абсолютно безумное техническое решение.
- Мэтью Грин о ZKPs

Решение, которое придумали криптографы, — это “делегированные вычисления” или “проверяемые вычисления”, и оно основано на теории интерактивных доказательств. Особенно сильно мы опираемся на методы из Zero Knowledge Proofs (ZKPs), которые представляют собой протоколы, позволяющие недоверенному проверяющему убедить проверяемого в истинности утверждения, не передавая при этом никакой дополнительной информации. Нулевое знание отлично подходит для других криптографических протоколов, таких как цифровые подписи. Proof-of-SQL не является ZKP. Просто в этом нет необходимости. Мы не пытаемся спрятать данные в хранилище данных, мы просто хотим избежать необходимости хранить их локально.

На самом деле, исследования в области интерактивных доказательств породили множество протоколов, так что мы можем выбирать, какие свойства нам нужны, и оптимизировать для получения наиболее производительной системы для защищенных от взлома SQL-запросов.

Я бы с удовольствием рассказал, как мы переходим от SQL-запроса к криптографическому обещанию, но мне сказали не вдаваться в такие подробности. Короткий ответ: мы превращаем это в математику. Я не имею в виду “в Пространстве и Времени мы превращаем это в математику”. Я имею в виду, что никто не знает, как сделать эти криптографические гарантии для программ без некоторого промежуточного представления, которое гораздо больше похоже на математику, чем на что-либо другое. Этот шаг называется арифметизацией, и он имеет решающее значение для эффективности Proof-of-SQL.

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

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

Мораль этой истории в том, что выбор промежуточного представления является наиболее важным выбором при проектировании для снижения накладных расходов. Чем ближе ваша математическая модель к самому вычислению, тем меньше “стоимость перевода”, возникающая на этапе арифметизации. Поэтому, ориентируясь конкретно на SQL, мы можем обрабатывать реальные сценарии использования, размеры которых немыслимы для современных SNARG общего назначения. Запросы к базам данных (а точнее, реляционная алгебра, которая лежит в их основе) имеют хорошую характеристику, которая делает их очень удобными для криптографических доказательств, но “универсальные” SNARK просто не приспособлены для использования этого преимущества.

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

• Вам не нужны тонны данных, вам нужна осмысленная аналитика, проверяемая на аутсорсинге.

• Криптографические инновации приблизили эту цель на расстояние удара.

• Арифметизация с учетом специфики домена выводит нас на финишную прямую

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

Оригинал: https://www.spaceandtime.io/blog/proof-of-sql

Website | Twitter | Linkedin | Discord | Telegram | Youtube | Instagram | Reddit | CrunchBase