Путеводитель Автостопом по ZK: Семинар для Разработчиков Aleo (ETHCC[5])

Этот семинар для разработчиков с ETHCC [5] предоставляет ранний предварительный просмотр децентрализованных частных приложений в Тестнете3 Aleo и того, как нулевое-разглашение сформирует строительные блоки для следующей волны этих приложений.

Сами Howard Wu (соучредитель Aleo) и Lambda Class (партнер экосистемы) продемонстрируют написание, запуск и развертывание приложений ZK на Aleo. Этот семинар посвящен последним техническим разработкам в snarkOS, snarkVM и Leo.

Ссылка на оригинальное видео: https://www.youtube.com/watch?v=fjfj5kFcQe4
Мой Дискорд: useless_dorozhkina#1394

Howard: Итак, что касается других аспектов, над которыми мы работаем, - это Пороговая Подпись. Идея пороговой подписи состоит в том, что, допустим, я хочу подписать какое-либо утверждение. Но в эту подпись делали свой вклад множество участников, поэтому у нас нет единственного приватного ключа. Вместо этого есть группа людей, у каждой из которых имеется часть приватного ключа. Мы хотим быть уверены, что, когда мы будем подписывать наше утверждение, на выходе всегда будет один и тот же адрес, который может быть распределен между группами людей, кто технически создает эту подпись.

В данном случае, мы используем FROST, и мы адаптировали его для того, чтобы поддерживать определенного держателя адреса, который мы используем в Aleo.

И, наконец, Coinbase Puzzle. Во-первых, сеть Aleo и дизайн ее консенсуса созданы для того, чтобы поощрять разработку оборудования для доказательств. Чтобы сделать доказательство настолько быстрым и с настолько большим потенциалом, насколько это возможно. И огромная часть этой цели - убедиться, что то, что мы делаем, будет стимулировать нужные стороны делать правильные, честные вещи: разрабатывать chips общего назначения и для создания доказательств. И, по моему мнению, один из самых больших вызовов - это создать систему, которая будет способна создавать специализированные chips для определенных утверждений. Я думаю, это и есть фундаментальная задача в разработке подобного рода паззла. Мы верим, что у нас получилось это разработать после Тестнета2. И теперь в Тестнете3 мы будем использовать FFT и MSM в качестве утверждений. В таком случае, размер доказательств будет примерно 100 байт, время проверки будет составлять около 1 миллисекунды на доказательство, а также доказательства в данной модели могут быть объединены. Это поможет нам быть уверенными в том, что рост этих доказательств on-chain остается относительно медленным, особенно в пропорции к транзакциям в сети, и что он позволяет лидеру эффективно проверять доказательство в реальном времени. При этом транзакции остаются основной логикой и основными вычислениями, которые делаются для проверки блоков.

И теперь перейдем к плану запуска. Мы скоро запустим Тестнет3! Те из вас, кто участвовал в Тестнете2, наверняка помнят, что это было безумие на протяжении шести месяцев! 10 тысяч нод и 30 тысяч людей, которые пробовали участвовать! Я думаю, Тестнет3 будет гораздо более спокойным, потому что мы разделим его на три части.

Первая Фаза начнется примерно через две недели, во время ее мы будем запускать genesis beacons. На высоком уровне, идея состоит в том, что мы для начала запустим ноды, чтобы поднять сеть с нуля. Кто угодно сможет поучаствовать, также запустив ноду. Можно будет запустить клиент, он сможет синхронизироваться и работать со всеми остальными. Но, самое главное то, что разработчики, смогут начать писать приложения и сразу же развертывать их в сети. Наша цель, чтобы как можно больше людей начали пробовать использовать Aleo и Leo, по сути, чтобы они начали создавать в экосистеме.

С начала сентября мы откроем паззлы доказательства, Coinbase Puzzles, о которых мы говорили ранее. Это позволит людям зарабатывать кредиты в сети, и эта фаза будет награждаемой, поэтому эти заработанные кредиты, в конце концов, перейдут в майннет; мы их распределим. Также, как и в Тестнете2 будет доступен лидерборд, чтобы все могли видеть, как развиваются сеть и ее работоспособность.

В Тестнете2 мы были очень удивлены тем, как быстро люди переходили от CPU до GPU, а после GPU начали пробовать использовать FPGA. Я думаю, Тестнет3 также будет очень интересным в этом плане.

Что касается bug bounty, самое главное, что мы хотим открыть в Тестнете3 - это bug bounty со стороны самих программ. В данный момент, как вы знаете, в любом программном обеспечении, когда вы его разрабатываете, имеются баги. и мы хотим убедиться в том, что мы находим их как можно больше, перед тем, как запуститься, особенно, когда речь идет о средствах. Очевидно, что мы также некоторые формы аудита, чтобы улучшить наших исходный код. Но ничто не работает лучше, чем наградить людей, если они его сломают! Данное объявление будет сделано в сентябре.

И, наконец, Третья Фаза, которая начнется в сентябре! Мы создали новую модель BFT, которая имеет дизайн, похожий на стейкинг. Фундаментальное ее значение заключается в том, что доказывающие застимулированы на то, чтобы выиграть столько токенов, сколько они захотят! И кто-то должен их проверять, скажем, "судьи". Это позволяет валидаторам в нашей модели обеспечивать и сохранять честность в сети. Таким образом, во-первых, гарантируются жизнеспособность и доступность, во-вторых, паззлы для доказывающий решаются верно и, в-третьих, количество токенов, которые должны быть распределены, также остается верным.

Также любой пользователь, у которого есть токены, сможет делегировать их, и с этого момента начать стейкать. Механизм тут довольно-таки базовый, большинство из вас с ним знакомы из вселенной Proof-of-Stake. Но это поможет нам разъяснить множество аспектов, различные правила, настройки. Я думаю, бóльшая часть этого механизма будет постепенно изменяться. Мы начнем с самых фундаментальных принципов. Но главное это то, что мы будем просить людей оставлять отзывы! Если они найдут проблемы в этом дизайне, мы будем рады узнать об этом и внести изменения в реальном времени Тестнета3, потому что до того, как испечется торт, гораздо проще решить проблемы, чем после того, как испечется торт!

Ну а теперь давайте переходить к делу!

Итак, какое значение у всего этого? Когда вы смотрите на ланшафт приложений в криптовалюте, вы видите:

Bitcoin - Общедоступные Деньги,
Ethereum - Общедоступные Приложения,
Zcash - Частные Деньги,
А функций Aleo состоит в том, чтобы создавать Частные Приложения.

Это компромисс сферы проектирования, в которой мы работаем.

В нашем дизайне газ больше не нужен для исполнения программ. Почему? Потому что мы исполняем их off-chain, создаем Доказательство с Нулевым Разглашением и передаем его в сеть. Это не значит, что в сети нет никакой платы за транзакции, но модель гораздо больше похожа на систему платы за транзакции в Bitcoin, потому что здесь по существу вы платите за приоритет, а не за размер вычислений. По-моему, это то, что было большой проблемой со стороны UX/UI в Ethereum. Я думаю, это огромный барьер для большинства людей, только приходящих в пространство, потому что большая плата за газ ограничивает удобство использования.

Для разработчиков в Ethereum выполнение программ очень ограничено. Я имею ввиду то, что каждое приложение получает лишь маленький отрывок времени, и каждый блок связан ограничением газа в 10 млн. И из-за этого они не могут писать выразительные приложения, не могут делать множество вычислений одновременно без того, чтобы забить весь блок. И я думаю, это очень ограничивает то, что можно создать в криптовалюте.

Естественно, идея Доказательств с Нулевым Разглашением состоит в том, что вы можете исполнить ваши программы офлайн. Но, что более важно, вы можете исполнить их гораздо быстрее, задействовав больше ядер. На практике это как раз-таки то, что вы не можете сделать в сети, задействование бóльшего количества ядер не обеспечит более быструю пропускную способность. Более того, подключение бóльшего количества машин только все замедлит, потому что накладные расходы на консенсус становятся больше. Со стороны разработки, это то, что мы всеми силами стараемся оптимизировать.

Как же это работает? У нас есть язык программирования Leo, который задумывался синтаксически быть похожим на Rust или на TypeScript, на высокоуровневые, строго типизированные языки. Он создан для того, чтобы специально писать схемы в домене Aleo. У него есть собственные типы конкретно для записей, для схем, для хеш-функций и так далее, мы обсудим их буквально через минуту.

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

Наконец, мы переходим к набору участвующих сторон и их взаимоотношениям. Давайте начинать.

Программирование в Aleo.

Как все работает? Когда вы хотите развернуть программу, вы создаете транзакцию, которая, во-первых, содержит в себе эту транзакцию и, во-вторых, содержит в себе проверяющие ключи всех вызванных в ней функций. Каждая функция имеет свой проверяющий ключ и свой сертификат, который проверяет то, что проверяющий ключ действителен. Это ловкий трюк из Marlin, который мы используем, чтобы убедиться, что проверяющий ключ правильный.

Отсюда вы можете направить программу валидаторам. Валидаторы запускают эти программы, оставляют их в реестре программ в сети. Вы можете рассматривать программы, как эффективно скомпилированные опкоды - это то, что размещается в сети. Любой может взять эти программы, использовать синтезатор и сгенерировать доказывающий ключ и проверяющий ключ. Для тех из вас, кто не знаком с этими ключами: идея заключается в том, что

доказывающий ключ позволяет выполнить программу. Во вселенной Solidity имеется смарт-контракт со множеством функций; каждая вызываемая функция в нашей вселенной имеет свой доказывающий ключ.
Каждая функция также имеет свой проверяющий ключ, он позволяет валидаторам в сети подтверждать, что ваше доказательство верно.

Эти ключи уникальны и детерминировано основаны на логике каждой функции и заключены в ней.

Второй шаг - это исполнение программы Aleo off-chain. В данном дизайне вызывающий запрашивает исполнение программы. На низком уровне это значит, что вызывающий подписывает вызов с названием функции и ее переменными. Цель здесь состоит в том, чтобы передать этот запрос для исполнения доказывающими, чтобы они смогли выполнить передачу характеристик, которые затем отправляются on-chain с помощью транзакции.

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

Для тех из вас, кто знаком с нашей кодовой базой, я хочу уточнить, что существует три основных репозитории, которые играют три разные роли в качестве трех участвующих сторон:

Для тех из вас, кому интересна роль валидатора, вы можете посмотреть на snarkOS. snarkOS - это, по существу, ноды в сети. Они запускают и оперируют стейт-машиной всех программ.
Проверяющие, в данном случае, используют snarkVM. snarkVM - это исполнитель с нулевым разглашением. Он берет опкоды, компилирует их до схем R1CS и выполняет их в Marlin. Это общее представление.
И, наконец, для разработчиков у нас имеется язык программирования Leo, который позволяет вам писать синтаксис высокого уровня.

Итак, то, о чем я действительно хочу - это показать то, чем мы занимаемся с Тестнета2! В Тестнете2 вы могли написать код на Leo, и мы сразу же переходили к передачу кода в R1CS. С тех пор мы создали два уровня взаимодействия. Их задача состоит в том, чтобы дать сети возможность контролировать версию. Нам нужно иметь возможность исправлять баги в схемах, если таковые обнаружатся. Синтезируя код Leo в инструкции, мы можем разместить их on-chain с помощью байт-кода, а затем выбрать те самые программы с багами, повторно синтезировать их доказывающий и проверяющий ключи, если они окажутся уязвимыми. По моему мнению, это важный шаг, переход от удобного интерфейса до чего-то практически развертываемого.

Сегодня я хочу начать с того, что покажу вам инструкции Aleo, которые похожи на высокоуровневый Assembly. А затем вернуться назад к Leo, с которым, я уверен, некоторые из вас знакомы, чтобы увидеть, как этот синтаксис компилируется до инструкций. Цель состоит в том, чтобы показать вам это, а затем мы продемонстрируем некоторые приложения, которые используют инструкции Aleo и Leo. Давайте приступим!

Инструкции Aleo

Начнем с инструкций Aleo. Что это такое? Вот самый простой пример:

function main:                    - initializes "main" function
    input r0 as field.public;     - input public register "r0"
    input r1 as field.private;    - input private register "r1"
    mul r0 r1 into r2;            - multiply "r0" & "r1" into "r2"
    output r2 as field.private;   - output private register "r2"

У нас есть функция main, в нее вводятся данные реестра, r0, который написан типизируется до field.public. Это значит, что элемент области выделяется публично, т.е. его будет видно on-chain, и кто-угодно может скачать эти данные. Строка

input r1 as field.private;

означает, что имеется элемент области, который будет приватно доступен on-chain. Он зашифрован адресом вызывающего. Это значение будет зашифровано адресом того, кто вызывает функцию main, таким образом, только этот человек сможет расшифровать значение. Оно опять-таки будет жить on-chain.

Затем мы переходим к исполнению. Мы перемножим реестры r0 и r1 и передадим результат в r2. Это значит, что r2 унаследует тип входных данных. В это случае, так как мы уже внутри схемы, нам не нужно переживать о видимости. Тип r2 будет такой же, как у field, и мы это знаем, основываясь на определении опкодов.

Наконец, у нас есть output. Он выведет данные r2 в качестве приватного реестра field.private. Опять-таки, это будет жить on-chain и будет зашифровано вашим адресом, вы сможете это увидеть.

Есть также дополнительный синтаксис, который мы хотим показать перед тем, как показать еще больше синтаксиса!

Это пример побольше, в нем демонстрируются интерфейсы. Интерфейсы позволяют вам определить пользовательские типы, т.е. я могу декларировать определенный тип данных, ввести его, и он унаследует то, что было определено в интерфейсе. Затем я могу провести над ним какие-либо операции и получить на выходе какую-либо переменную. Это общее представление. Кажется, было бы более продуктивно конкретно разбирать примеры и, по мере того, как я разбираю, вы сможете увидеть, как все работает. Но пока я просто хочу дать вам представление о том, как визуально выглядит язык, похожий на Assembly, и как он чувствуется.

Код Leo и Инструкции Aleo

Живая демонстрация

Давайте начнем с того, что просто напишем "aleo".

Имеется CLI, который, по сути, является компилятором. Он синтезирует инструкции, какие мы хотим, и выполнит их за нас.

Мы можем начать с создания нового пакета. Назовем его "aleo new foo".

Вуаля! Вы можете видеть, что создалась директория под названием "foo". Давайте перейдем в "foo" и выведем ее компоненты.

Мы только что создали три вещи:

README.md файл, который описывает, как выполнять и запускать то, что вам нужно,
main.aleo файл, на котором мы сейчас подробно остановимся,
program.json - это наш конфигурационный файл.

Давайте их откроем.

Это главная программа foo.aleo, которая только что была создана:

В ней функция hello принимает значения двух неподписанных целых чисел размером в 32 бит, складывает их и выводит r2, результат сложения.

Перед тем, как я приступлю к исполнению программы, я хочу отметить, что в файле program.json у нас есть автоматически сгенерированный аккаунт разработчика, у него есть приватный ключ и адрес.

Это позволяет вам быстро начать тестировать его. План, скорее всего, будет заключаться в том, чтобы интегрировать их в CLI, чтобы они могли безопасно храниться зашифрованными в файл на вашем устройстве. Но, чтобы скорее начать с разработкой, мы внесли их в этот файл.

Затем я могу ввести "aleo build" и по мере того, как программа начнет выполняться, она загрузит универсальные настройки, в данном случае, эти настройки будут сохранены с церемонии запуска. Программа строит функцию hello, и теперь у нас есть новая папка build!

Если мы выведем компоненты build, мы увидим hello.prover, hello.verifier и main.avm.

main.avm - это байт-код, который мы только что показывали на экране,
hello.prover содержит доказывающий ключ и некоторые дополнительные параметры,
hello.verifier - проверяющий ключ и также некоторые дополнительные параметры.

Теперь, если я хочу запустить программу, я могу написать:

"aleo run hello"

и, как мы сказали, мы должны добавить две переменные, r1 и r2:

"aleo run hello" 5u32 95u32

Программа выполнилась за 807 миллисекунд, и на выходе мы получили 100u32.

Фундаментально, это модель, с которой мы начнем работать и которую будем расширять до чего-то большего.

Теперь я хочу начать с примера токена.

Здесь у нас программа token.aleo.

Также у нас есть новый синтаксис, который мы не видели ранее, record, запись.

record token:
    // Владелец токена.
    owner as address.private;
    // Баланс Aleo (в gates).
    gates as u64.private;
    // Баланс токенов.
    amount as u64.private;

record - это то же самое, что и interface. Это структура, которая имеет владельца и переменные, предписанные ей. Это первые два члена в коде. Эти два члена обязаны присутствовать в записи, компилятор выдаст ошибку, если у вас их не будет.

И теперь вы можете создать столько произвольных типов, сколько захотите, даже ноль!

owner сообщает, кто владеет записью;
gates - это базовая единица наименований в Aleo.
1 млн gates = 1 кредит.
Это значение, которое содержится в записи и которое сообщает, сколько денег содержится в ней содержится.
amount - в данном случае, это баланс токенов для приложения, которое мы рассматриваем.

Далее у нас идут две функции: mint и transfer.

// Функция 'mint'инициализирует новую запись с определенным количеством
// токенов в 'r1' для получателя в 'r0'.
function mint:
    input r0 as address.private;
    input r1 as u64.private;
    cast r0 0u64 r1 into r2 as token.record;
    output r2 as token.record;

mint делает абсолютно то, о чем вы подумали. Передайте в нее адрес и количество, и она заминтит вам запись человека с данным количеством денег в ней. Здесь мы используем оператор cast, который вносит owner, gates и amount в r2 как token.record. Таким образом, мы выводим запись, которую только что создали.

Давайте запустим программу.

Мы можем увидеть, что у нас есть несколько папок:

Я могу ввести:

aleo run mint

Давайте введем новый адрес:

Итак, за 1.2 секунды программа вывела новую запись, mint. Кстати, то, как мы сериализуем и распознаем объекты, очень похоже на .json.

Теперь давайте перейдем к логике transfer:

// Функция "transfer" отправляет определенное количество токенов получателю
// из предоставленной записи токена.
function transfer:
    // Введите запись отправителя.
    input r0 as token.record;
    // Введите получателя токенов.
    input r1 as address.private;
    // Введите количество токенов.
    input r2 as u64.private;

Теперь я хочу вычесть из количества, с которого я начал, количество, которое я отправил, и получить количество, которое у меня останется:

    // Проверяет, что данная запись токена имеет достаточный баланс.
    // Эта операция "sub" безопасна, и доказательство закончится неудачей, 
    // если произойдет underflow. Выходной реестр 'r3' 
    // удерживает измененное количество, чтобы вернуть его отправителю.
    sub r0.amount r2 into r3;

Все операторы в инструкциях Aleo безопасны! В данной концепции математика безопасна по умолчанию.

У нас также имеются и вариации для underflow/overflow: sub.w, add.w и т.д. W здесь означает "wrapped". Таким образом, если вы добавили больше, чем максимальное значение u32, оно сбросится до нуля и продолжится с того момента, которое вы можете предположить, зная, как работает модульная арифметика.

    // Производит запись токена для конкретного получателя.
    cast r1 0u64 r2 into r4 as token.record;

Мы вводим r1 -адрес получателя; 0u64 - ноль gates, никаких токенов Aleo и вводим количество, которое хотим отправить. Также мы вводим реестр r4 как token.record.

Для себя же:

    // Производит запись токена с измененным количеством для отправителя.
    cast r0.owner r0.gates r3 into r5 as token.record;

Теперь мы выводим значения реестров r4 и r5:

    // Выводит запись получателя.
    output r4 as token.record;
    // Выводит измененную запись отправителя.
    output r5 as token.record;

Давайте выполним эту программу.

Итак, мы вызываем функцию "transfer":

aleo run transfer

Заметьте, что дальше идут кавычки, это важно для CLI, ему это нужно, т.к. это просто терминал.

У нас тут запись с количеством, 100u64, как раньше. Мы отправляем это на другой адрес ниже с 100u64..

Вы можете видеть, что если я нажимаю "Выполнить":

Теперь, спустя две секунды, мы получили две новые записи. Первая из них, r4, - это получатель, он получил 100 новых кредитов. А вторая, r5, - это я, у которого ничего не осталось. Эта программа может быть передана в сеть, но так как мы ее туда не передавали, мы можем повторно выполнять ее!

Давайте введем другое число, допустим, 10:

На выходу получилось 10 для получателя, а 90 вернулось назад ко мне!

Это может быть отправлено в сеть, которая проверит фиксации записей, которые тратятся. Если получается 0, это уникально число, т.е. не происходит двойного расходования. А для выходных данных у нас есть новые записи и новые фиксации, которые к ним прикреплены.

Сеть на самом деле не может видеть никакие из данных значений в транзакции, потому что все очень сильно зашифровано адресом вызывающего. Данные, принимаемые получателями, также шифруются под их адресами.

Давайте рассмотрим еще один пример, и затем я передам микрофон дальше. Я хочу показать вам кое-что интересное, Inter-Contract Call.

program swap.aleo;

// Функция "swap" передает владение записью токена А владельцу записи 
// токена В и т.д.
function swap:
    // Введите запись для токена А.
    input r0 as eth.aleo/eth.record;
    // Введите запись для токена В.
    input r1 as usdc.aleo/usdc.record;
    
    // Отправьте запись для токена А владельцу токена В.
    call eth.aleo/transfer r0 r1.owner r0.amount into r2 r3;
    
    // Отправьте запись для токена В владельцу токена А.
    call usdc.aleo/transfer r1 r0.owner r1.amount into r4 r5;
    
    // Выведите новую запись для токена А.
    output r2 as eth.aleo/eth.record;
    // Выведите новую запись для токена В.
    output r4 as usdc.aleo/usdc.record;

Заметьте, что мы отправим весь баланс, без остатка, поэтому на выходе у нас только две переменные: r2 и r4.

Давайте выполним программу.

Перед тем, как я нажму "Enter" я поясню некоторые моменты. Здесь приведены две записи, заметьте, что они выглядят одинаково. Почему? Потому что их структура была одинаковой, определение их записей было одинаковым, это два одинаковых контракта токенов. Если бы один контракт отличался от другого, они бы естественно имели два разных значения.

С началом выполнения, во-первых, выполнится первый call, затем выполнится следующий call и только потом завершится последний call, который является изначальной функцией.

Мы видим первый transfer для ETH, второй transfer для USDC и завершенный swap. И теперь у нас есть две новые записи. Для демонстрации я случайно взял два одинаковых адреса, простите! Но, в конце концов, программа производит swap между этими двумя участниками, это ключевой вывод.

Еще важно отметить, что такая модель позволяет вам провести операцию очень быстро, примерно за две секунды для каждого call.

Теперь я хочу передать микрофон ребятам из LambdaClass, потому что мы будем использовать примитивы, которые только что разобрали, чтобы создать гораздо более объемное приложение! Я думаю, это будет очень интересно. А затем я покажу, как со всем этим работает Leo!

Federico: Привет! Меня зовут Federico, я главный исполнительный директор LambdaClass.

Итак, это мы! Я видел лучшее описание нас: мы нечто вроде компании клуба любителей, которая создает сложные и интересные вещи.

Я хочу поговорить о двух маленьких проектах. Первый называется MACI. Мы созвонились с Alex, главным операционным директором Aleo, и он рассказал нам о MACI. Название мне показалось странным, я даже не знал, что оно обозначает, т.к. я не занимался криптографией, я больше традиционный разработчик в Web3.0. И я люблю математику, но я начал более подробно изучать детали MACI и подумал, что я не уверен, смогу ли создать нечто подобное, т.к. это не связано с вещами, в которых у меня есть опыт.

Однако, нам удалось выучить множество вещей из того, что строили и создавали в Aleo.

И, в конце концов, мы создали CLI. Он может показаться очень простым.

С моей точки зрения, я вижу его как приватный сервер для голосования, в котором никто не имеет такой доступ к голосам, как, например в Ethereum, в DAO. Там, когда вы голосуете, вы можете видеть, кто за что проголосовал.

Идея MACI заключается в том, что вы можете голосовать, но вы не можете знать, кто за что проголосовал. Также вы можете быть уверены, что человек, который подсчитывает голоса, не может их поменять. Вы голосуете с помощью CLI, а результаты можно наблюдать в Explorer.

Одной из важных частей также было то, пользователи имеют возможность изменить свой голос, если что-то случилось.

Как я уже упомянул, это не те вещи, которые я привык создавать, но мы справились всего за два месяца. И, если вы посмотрите кодовую базу Ethereum, как это сделали мы, чтобы понять, как она работает, вы увидите, как JavaScript, TypeScript, Solidity соединены друг с другом. С точки зрения разработчика, все выглядит очень беспорядочно. Однако, для нас разработка оказалась очень легкой. Человек, ответственный за написание этой программы, даже не знал Rust! Он был традиционным разработчиком full stack или frontend. И он сделал то, что было довольно-таки сложно для команды исследователей, и справился достаточно быстро!

С моей точки зрения, это не только значит, что он отличный разработчик, но и то, что Aleo имеет замечательную технологию.

Это MVP, над которым мы работали до вчерашнего дня. Мы закончили его только вчера, поэтому возможно будут встречаться некоторые проблемы. Мне очень хочется вам об этом рассказать, т.к. это рулетка!

Если вы когда-либо были в казино или видели ее в кино, вы видели, как она работает. Вы выбираете номер, на который хотите поставить, на красное или черное.

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

Идея же, по сути, всего Aleo состоит в том, что вы можете быть уверены, что случайность работает верно, сервер бэкенда не делает ничего плохого.

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

Это код, который состоит всего из 16 строк.

Его очень легко понять. Это Assembly, т.е. высокий уровень. Тут есть хэши и другие вещи, которые вы обычно можете делать в Assembly. И, очевидно, когда у вас есть нечто подобное, вы можете создавать более высокие языки такие, как Leo. По-моему, то, что даже человек, который не знал Assembly две недели назад, смог создать нечто подобное, означает Leo очень легок в использовании.

Несмотря на то, что я занимаюсь программированием 20 лет, мне было тяжело выучить Solidity. У этого языка множество нюансов, множество вещей, которые нужно выучить и всегда нужно быть осторожным. Здесь все в точности наоборот.

Когда я обновляю веб-страницу, я минчу токены. Затем я могу сделать ставку, я поставлю на 8, и можно выбрать, как много токенов я хочу поставить.

В системе пока что не было сделано ни одной транзакции:

Это мой аккаунт, на котором у меня имеется 50 токенов:

А это адрес казино и количество токенов, которое у него имеется:

Я поставлю 3 токена на номер 8. Рулетка начинает крутится, это займет несколько секунд; здесь есть несколько моментов, которые мы хотим улучшить.

Похоже, что выпало 6, а ставил я на 8. Очевидно, что я проиграл. Как вы можете видеть, казино получило три токена, а я потерял их. Также эта транзакция появилась в списке.

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

Это код:

В нем у нас есть gates, нечто вроде балансов, amount токенов.

Эта часть выполняется в начале, когда мы обновляем страницу:

А это сам процесс делания ставок:

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

Следующее, о чем я хочу рассказать, это то, что мы уже разрабатываем неофициальную библиотеку MVP для Leo:

Вы можете увидеть эту библиотеку на GitHub:

Пятеро людей из нашей команды уже начали разработку различных модулей.

Последнее, что я хочу упомянуть, у нас уже есть несколько идей того, что мы хотим исполнить:

Что удивительно, мы создали проект Maci с джунами в первой ссылке за два месяца; второй проект, Roullet - за две недели, и нам пришлось выучить инструкции Aleo; Stdlib мы также создали за одну или две недели. Я даю вам слово, что, если мы начнем привлекать к этому больше людей, будет разрабатываться еще быстрее! Мы понимаем эти вещи гораздо лучше, чем сложные инженерные проблемы Ethereum. По-моему, Aleo гораздо более продуман со стороны разработки. Это то, что я чувствую. Я не профессиональный разработчик на Solidity, но я понимаю, что последний состоит из большего количества низкоуровневых вещей. В нем вы должны видеть шаги, компилировать их и т.д. Я поражен тем, насколько легко было разрабатывать на Aleo до сих пор, и я думаю, что это правильный путь в будущее! Он конечно подходит не для всего, но у него есть множество адаптаций!

Если у вас есть какие-либо вопросы, пишите мне в Twitter!

Howard: Отлично, спасибо!

Я хотел бы еще быстро рассказать кое-что для тех людей, кто знаком с Leo. Что касается токенов, то, что мы только что делали в демонстрации с инструкциями Aleo, mint и transfer, уже доступны в Leo!

Это код прямо из GitHub, вы можете зайти туда и посмотреть примеры - они там! Если мы рассмотрим запись, о которой мы говорили, с owner, gates и amount; и отдельно рассмотрим функцию transfer - они делают то же самое, что мы обсуждали ранее в плане вычислений.

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

Мы также добавили групповые типы для людей, которые занимаются криптографией, заполнили шкалу арифметики для разных типов протоколов. Leo изначально поддерживает инструкции Aleo, вы можете добавлять их, выполнять над ними операции, можете получать их. И, я думаю, самое крутое - это количество различных хеш-функций, фиксаций - они доступны для того, чтобы создавать различные типы вычислений в криптографических протоколах с помощью Leo, который затем могут быть исполнены и перенаправлены on-chain. Они также синтезируются до опкодов. Отсюда вы можете создавать гораздо более объемные программы.

Мы очень взволнованы тем, чтобы опробовать эти вещи, и, я думаю, будет очень здорово увидеть это в Тестнете3!

У нас закончилось время, так что я остановлюсь здесь, но спасибо за то, что вы пришли и послушали нас. Надеюсь, вы найдете время также посмотреть то, о чем слушали сегодня!

Спасибо за внимание! :)