Встреча DevEx Subgovernance №26 от 22.04.2021

Встреча DevEx Subgovernance №26 от 22.04.2021

Обсудили, как будет проходить быстрый конкурс среди победителей DeNS по доработкам и что ожидается в итоге, а также подискутировали на тему предстоящих конкурсов ZKP.

DeNS: довести до продакшн-реди

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

Решение победителя будет запущено 7 мая в main network production-ready (символически можно запустить аукцион). Если будет больше одного решения, пройдет голосование. Все критерии указаны в пропоузале. Если же что-то будет не выполнено, то судьям придется ставить reject.

Обновления в будущем будут проводиться через сет-код. Все подробности можно увидеть в описании пропоузала Decentralized Name Service (DeNS) — Part II.

Предложение конкурсов на базе ZKP-системы

Павел П представил нового участника встречи — Михаила Комарова из команды NilFoundation, у которых возникла необходимость запустить конкурсы. Чтобы сэкономить время, они не стали инициировать отдельный Subgovernance, потому и обратились в существующий — DevEX SG.

Первый предлагаемый контест — на разные решения на базе ZKP-системы (как составлять circuit — есть на GitHub). Нужно сделать некие инструменты к тестовому кластеру, юзкейсы для использования инструкции.

Командой NilFoundation подняты несколько нод С++ с модифицированным кодом, и, по их представителя, в результате поднятия отдельного кластера (блокчейна), нужно провести конкурс на юзкейсы, в рамках которого появляются юзкейсы инструкции. “Вследствие чего, — поясняет Михаил, — возможно, будет принято решение, хотим ли мы обновлять основной набор нод на спецификацию или нет. Нам нужен набор юзкейсов, доказывающий, что эта история достаточно работоспособна, стабильна для обновления основного набора нод”.

Павел П уточнил, что если все увидят, что все работает, то можно влить эти инструкции в виртуальную машину в mainnet, но придется обновить и SDK, потому что это тоже виртуальная машина. “А дальше все эти юзкейсы будут работать на mainnet, — добавил Павел П, — что очень важно, потому что нам и зеткэш нужен, и много еще чего в ZKP”.

В ходе встречи решили, что для проведения первого конкурса хватит одного месяца. Но возник вопрос, будут ли готовы судьи жюри судить контест подобного рода? Однако, по словам Павла П, в DevEX Subgovernance собраны все самые технические люди. Также он уверен, что circuit сложно писать, но проверять — достаточно легко. Для удобства Митя все же предложил составить инструкцию для жюри.

В результате первого конкурса не ожидается продакшн-реди, но нужно, чтобы решение работало. Митя настроен скептически, что можно написать лишь за отведенный месяц, предположив: “Билетик?” Павел П возразил, что даже если это будет билетик — неважно: “В этом же и фишка, чтобы разработчики из нашей экосистемы пощупали ZKP. Мы хотим проверить, что  криптография работает и собрать какие-то мысли. Все”.

На данный момент готовый пропоузал Groth16 zkSNARK Proof Verification Use Cases можно уже прочитать на форуме и ознакомиться с подробными критериями для подачи заявок.

Видение второго конкурса ZKP

Второй предлагаемый конкурс от команды Михаила Комарова — сделать конкретный circuit для RocksDB, Proof-of-Storage, чтобы потом использовать circuit для воркчейна storage. “Есть filecoins в proof-of-storage, где наказывается хранение в APFS. Нужно сделать аналогию”, — пояснил Павел П.

Перед следующим конкурсом Митя предложил провести конкурс на дизайн storage — дизайн спеки, как это должно быть сделано. Или же создать отдельный контест на то, чтобы “конкретно хорошо сформулированную маленькую часть Proof-of-Storage сделать на ZKP”. Но это будет не solution storage.

Павел П считает, что ZKP — это элемент сторадж: “Понятно, что в данном конкурсе не будет описан алгоритм консенсуса. Но когда у тебя написан circuit, который доказывает хранение в RocksDB каких-то данных в какой-то структуре, то ты уже на базе этого можешь написать консенсус, как у тебя будет слэшиться и ревордиться”.

В любом случае, все это еще будет решаться. А пока все внимание — на первый конкурс ZKP Groth16 zkSNARK Proof Verification Use Cases.

Узнайте больше про Everscale
Подпишитесь на наши социальные сети и будьте в курсе актуальных новостей
SUBSCRIBE ON SOCIAL
Free TON House
Первоисточник