Caspin & Lisk
Lisk
Ты когда-нибудь задумывалась, как бы выглядела платформа для смарт-контрактов, защищенная квантовыми технологиями? У меня накидалось несколько безумных идей, где переплетаются доказательства с нулевым разглашением и постквантовая криптография — интересно послушаешь?
Caspin
Конечно, мне интересно. Какие основные идеи ты выстраиваешь? Как ты совмещаешь zero-knowledge с постквантовыми элементами? Это может быть прорыв, если выдержит проверку.
Lisk
Слушай, изначально нужно сохранить слой конфиденциальности пользователя – типа ZK-SNARK, который позволяет доказать "Я – действительный держатель", не раскрывая адрес – поверх цепочки, работающей на пост-квантовом обмене ключами. Представь себе, что слой консенсуса использует алгоритм на основе решёток (вроде NewHope или Kyber) для голосования в системе Proof-of-Stake, чтобы даже квантовый компьютер не мог взломать валидацию доли. Затем, каждое выполнение контракта по-прежнему использует ZK-SNARK для скрытия входных и выходных данных, но схема коммита внутри SNARK построена с использованием хеширования на основе решёток, таким образом, вся система доказательств становится устойчивой к квантовым вычислениям. На практике получится двухслойное доказательство: сначала PQ-доказательство доли аутентифицирует блок, а затем ZK-доказательство проверяет логику контракта. Язык смарт-контрактов может остаться похожим на Solidity, но компилятор внедряет примитивы хеширования на основе решёток "под капотом". Так мы получим конфиденциальность, производительность и квантовую безопасность в одном пакете.
Caspin
Интересное решение – сначала стейкинг PQ, потом zk-приватность. Мне было бы любопытно посмотреть на падение производительности из-за хешей на решётках в SNARK-коммите. И ещё подумай, как компилятор будет управлять ключами для операций на решётках – возможно, понадобится защищённая среда исполнения или что-то в этом роде. Но в целом – неплохое направление; квантово-устойчивая приватность на цепочке с PQ-консенсусом – это следующий этап развития.
Lisk
Привет, вот что я думаю. Главная загвоздка здесь — производительность. Решетчатые хеши, они заметно тяжелее эллиптических кривых, поэтому доказательства SNARK будут больше — примерно в 2-3 раза, и время настройки увеличится. Но можно держать размеры поля небольшими и использовать SNARK с небольшим количеством раундов, например, Plonk, чтобы компенсировать это. По поводу ключей, я думаю использовать что-то вроде SGX enclave для генерации и хранения решетчатых секретных ключей, а потом экспортировать публичные параметры один раз и использовать их во всех контрактах. Так разработчику не придется париться с ротацией ключей. Сделаем сначала небольшую тестовую цепочку, посмотрим, как будет масштабироваться стоимость газа, и подстроим схему коммита, чтобы найти оптимальный вариант. Как тебе такой план?