Еженедельный прямой эфир 2 сентября 2022 года - Безопасность

Алехо: На этой неделе у нас очень особенный гость: Роберт. Он один из самых известных в мире аудиторов Move и экспертов по безопасности. Он провел аудит множества проектов и основных протоколов. Мы очень рады работать с Робертом и очень рады видеть его у нас в гостях. В свободное время он выступает со стендап-комедией, так что, возможно, мы сможем увидеть и эту часть его личности. Давайте попросим Роберта представиться.

Роберт: Спасибо, что пригласили нас! На данный момент у меня нет готовых шуток, но, возможно, я придумаю их по ходу дела. Я помогаю руководить OtterSec, фирмой по аудиту смарт-контрактов. Мы много изучаем внутреннее устройство Move и стараемся глубоко понимать как уровень VM, так и уровень SDK для Aptos. Благодаря этому мы пытаемся гарантировать определенные аспекты безопасности. В прошлом мы тесно сотрудничали с такими крупными организациями, как Alameda Research, Jump Crypto, а также у нас есть договоренности с Pontem Foundation о проведении аудита их основного кода. Я очень рад быть в этом месте, чтобы рассказать больше о том, что делает Move таким интересным языком, а также о том, как мы работаем с Pontem над безопасностью их приложений, потому что вы уделяете большое внимание безопасности.  

Алехо: Замечательно, спасибо. Может быть, мы начнем с этого. Скажите, что вас привлекает в Move? Чем он отличается от других? Какие сдвиги в парадигме вы видите, особенно в области безопасности?

Роберт: Это действительно хороший вопрос. На самом деле, это пока что альфа-версия, но мы собираемся опубликовать статью в блоге на эту тему, возможно, через несколько дней. Я думаю, что Move как язык очень интересен. Это одна из главных причин перехода на Aptos. Я бы назвал Move Rust для блокчейна; он более специфичен для конкретной области, что означает, что он может избежать многих проблем общего назначения, которые есть в Rust. Например, при использовании Move вам не нужно вручную выполнять сортировку(serialize ) или реорганизацию(deserialize ) данных. Это язык более высокого уровня, который дает разработчикам больше инструментов для написания более безопасных программ.  

Можно ли здесь перейти к техническим аспектам? Я думаю, что один действительно классный специфический аспект Move заключается в том, что VM чрезвычайно [универсален]. Одним из примеров этого является то, что ссылки доступны изначально, как будто они являются ценностью первого класса в самой ВМ Move. Поэтому вы можете, например, в бикоде, поместить ссылку в стек, и вы также можете разыменовать ссылку напрямую. Следствием этого является то, что когда вы хотите вызвать функцию, вы напрямую передаете ссылку. В целом, Move - это гораздо более специфичный для конкретной области, блокчейна, язык высокого уровня, который, как мне кажется, решает многие проблемы безопасности, которые мы видим в обычном программировании.

Алехо: Давайте разложим по полочкам, что значит быть ценностью первого класса? Какова аналогия?

Роберт: Это хороший вопрос. Итак, первый класс означает, что он просто поддерживается виртуальной машиной. В отличие от этого, например, при обработке(deserializing) данных с помощью Rust вам необходимо иметь какое-то промежуточное представление для этого значения, или какое-то представление для преобразования байтов в то, что использует ваша программа. Вам нужен этот промежуточный шаг, на котором вы конвертируете необработанное двоичное значение в пригодное для использования значение Rust. С другой стороны, Move просто полностью игнорирует этот шаг, если вы можете просто использовать значение напрямую.

Алехо: Помогите мне понять это немного больше. Является ли ETH нативным? Является ли токен Compound или UNI ценностью первого класса? Как это соотносится с Ethereum?

Роберт: Для ETH у вас есть контракт, а затем вам нужно иметь бэкэнд для загрузки значений, поэтому у вас нет доступа первого класса к самой структуре более высокого уровня. Например, вы не можете передать ссылку на токен. Вам нужно будет вызвать контракт, чтобы получить значение. Этот промежуточный шаг все еще присутствует, но он немного отличается, потому что все состояния контрактов хранятся внутри самих контрактов.  

Алехо: Значит, я должен вызвать контракт, например, контракт ERC-20?

Роберт: Да.

Алехо: Это тоже более эффективно? Помимо безопасности, я экономлю на газе?

Роберт: Ну, я думаю, эта часть отчасти отделена от экономии газа. Я думаю, что Move как язык создан для того, чтобы быть очень быстрым. Он масштабируемый, поэтому затраты пользователей также должны быть ниже. Хотя газ - это как бы родная концепция VM, поэтому газ Move обозначается в совершенно других единицах, чем газ ETH или Solana.

Алехо: Давайте сделаем это сравнение более абстрактным. Что произойдет, если мы поставим их рядом с Cosmos или Polkadot, какой из них будет работать лучше? Move или EVM? Какие аспекты мы должны отслеживать?

Роберт: Теоретически, вы можете написать эти контракты на любом языке. Есть много примеров, я бы сказал, вероятно, довольно безопасных контрактов в Ethereum или любой другой сети. Но я думаю, что для меня главным моментом является то, что Move безопаснее по умолчанию. Он позволяет вам писать более безопасные контракты, не прилагая особых усилий и не уделяя этому много внимания.

Алехо: То есть вы хотите сказать, что теперь гораздо сложнее выстрелить себе в ногу?

Роберт: Надеюсь! Никаких гарантий. В идеале - да. Я знаю, что Pontem много заботится о безопасности, но, честно говоря, я думаю, что есть много разработчиков смарт-контрактов, которые либо не очень заботятся о безопасности, либо не понимают всех последствий. Они просто пишут код, который они развертывают в mainnet как можно быстрее, и это часто заканчивается тем, что они сами себя подставляют под удар.

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

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

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

Алехо: Есть ли какой-то способ, с помощью которого мы как протокол можем сделать это без проблем? Есть ли какая-то проверка, которую вы можете сделать как аудитор, чтобы сказать, что версия, которая сейчас находится на Github, это та, которую вы проверяли? Может ли это быть в кошельке, или в каком-то месте, где мы можем увидеть подтверждения или сигналы?

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

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

Алехо: Это действительно хорошая идея. Мы обязательно подумаем, как сделать такую функцию и добавить ее в дорожную карту. Это также хороший поворот к безопасности кошелька. Учитывая, что кошелек - это интерфейс в метавселенную, расскажите мне подробнее: на что нам следует обратить внимание в плане безопасности кошелька? Недавно произошли взломы. Мы рассмотрим слона в комнате - то, что произошло с Solana. Может быть, вы могли бы высказать свое мнение о том, как пользователи и проекты могут защитить себя, а также пользователей? Что вы думаете о кошельке как интерфейсе или об избавлении от браузера как посредника?

Роберт: Здесь есть много вопросов, которые нужно распаковать. Первый - это безопасность. Лично я считаю, что безопасность кошельков долгое время оставалась под пристальным вниманием. Людей это очень волнует. Они часто видят, что эти dApps были потенциально скомпрометированы, но до этого события в Солане никого не волновало, был ли проведен аудит кошельков. Что, если подумать, не имеет особого смысла, потому что кошельки - это, по сути, мост в этот мир криптовалют. Если этот централизованный мост будет взломан, то все, с чем вы взаимодействуете, также потенциально может быть взломано. Это как единая точка отказа для всего, с чем вы взаимодействуете.

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

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

Алехо: Это то, что могло быть обнаружено в аудиторском отчете?

Роберт: Да, но я думаю, что вам придется искать это специально. Я думаю, что разработчики должны быть очень осторожны, когда занимаются подобными вещами. Либо вам нужна внешняя фирма, которая специально занимается тем, что нужно искать, либо вам нужно потратить много времени на поиск таких крайних случаев, когда конфиденциальные данные пользователя могут быть переданы таким образом, что вы этого не предполагаете. Я думаю, что это тревожный сигнал для кошельков в целом. Существует множество кошельков, и, честно говоря, многие из них не слишком заботятся о безопасности. Мы действительно обнаружили и сообщили о проблемах в ряде кошельков за пределами Phantom. Хотя это немного тревожно, мы также видим, что некоторые кошельки, с которыми мы работали в прошлом, улучшили свою позицию. Надеемся, что после событий на Solana, больше внимания будет уделяться безопасности и со стороны кошельков.

Алехо: Эта центральная точка отказа на самом деле довольно страшна. Подумайте, сколько людей используют Metamask вместо других кошельков на Ethereum. Как мы решим эту проблему? Существует ли такая вещь, как децентрализованный кошелек?

Роберт: Лично я думаю, что решение проблемы заключается в том, чтобы мы, как пользователи, добивались большего внимания к безопасности. Работайте только с теми кошельками, у которых есть надежный партнер по безопасности. Задавайте вопросы о том, что кошелек сделал для обеспечения своей безопасности. Потенциально вы можете иметь децентрализованный кошелек, но я не совсем понимаю, как это будет работать. Одно из соображений заключается в том, что код для кошелька должен быть несколько централизованным. Я не уверен, что кодовая база кошелька может быть децентрализованной. То есть, возможно, у вас может быть несколько фронт-эндов или что-то в этом роде, но для пользователя всегда будет существовать единая точка или единые точки отказа.

Алехо: Считаете ли вы, что кошельки должны быть такими же тщательными в своих проверках и такими же публичными в своих отчетах, как и dApps смарт-контрактов?

Роберт: Я думаю, что кошельки так же, если не более, важны, чем dApps, с точки зрения их безопасности. Пользователи должны быть уверены, что используемый ими кошелек не подпишет случайно транзакцию, которую они не хотят подписывать, и что он корректно отображает все транзакции. Было проведено интересное исследование о том, можно ли, будучи контрактом, понять, что вы находитесь в симуляции, например, в вызове RPC simulate, и изменить свое поведение на основе этого. Конечно, вам не следует взаимодействовать с контрактами, которым вы не доверяете, но это также интересный вопрос: можете ли вы действительно доверять тому, что происходит на уровне симуляции? Хотя я не знаю, является ли это уязвимостью кошелька как таковой. Я бы сказал, что это больше относится к дизайну VM. Я думаю, что кошельки определенно должны много заботиться о безопасности, а пользователи должны добиваться безопасности кошельков, которые они используют. В конце концов, потребность в безопасности должна исходить от пользователей. Если пользователи не заботятся о безопасности, то и кошельки не будут заботиться о ней. Но если пользователи требуют безопасности, тогда у кошельков будет стимул проводить аудит своего кода.

Алехо: Мне пришла в голову одна мысль. А что если люди просто скачают и запустят кошелек сами? Он не отправляет никакой информации. Может ли это потенциально сработать? Или, может быть, некая структура, где, даже если вам нужны дополнительные вычисления на вашем компьютере или телефоне, или что-то еще, вам не нужно доверять третьей стороне, чтобы она отправляла вам информацию? Это часть этики в отношении Web2 и Web3, верно? Как и в Web2, вы хотите отслеживать все. Вы хотите видеть, куда нажимает пользователь. Все эти журналы могут быть полезны для улучшения продукта, но это также обоюдоострый меч, верно?

Роберт: Да, определенно. Я думаю, что даже в Web2 существует огромное количество опасений по поводу загрузки конфиденциальных данных. Хотя проблема в Web2 в том, что это не прямая потеря. Даже если вы украдете кучу имен пользователей и паролей, у вас не будет прямого доступа к деньгам, в отличие от Web3. Если у вас есть закрытый ключ чьего-то кошелька, вы можете просто немедленно слить его средства. Вот почему я считаю, что Web3 намного страшнее.

Алехо: Да, это имеет смысл. Это действительно хорошая обратная связь. Честно говоря, на всех веб-сайтах мы, вероятно, не должны логировать ничего, ни электронную почту, ни IP-адреса встреч, ни что-либо еще. Мы не должны отправлять их на любой сервер AWS, хотя я знаю, что это полезно. Мы можем поговорить об этом: как сделать простейшую вещь, которая собирает как можно меньше информации, чтобы не было даже утечки, потому что вы ничего не собираете?

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

Алехо: Здесь даже есть проблемы, выходящие за рамки просто утечки вашей личной информации. Существует также потенциально MEV, максимальная извлекаемая ценность. Эта централизация, или центральная точка отказа, означает, что эти кошельки имеют много информации, которая может быть очень ценной для трейдеров, которые могут пытаться заработать на сделках, которые вы совершаете. Люди, вероятно, знакомы с высокочастотной торговлей, это Web2, это традиционные финансы, та же проблема того, что люди называют "front running", или "back running", или "sandwich attacks", или любые другие формы MEV. Я хотел бы услышать ваши мысли по этому поводу.

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

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

Роберт: Да, я думаю, что поток платежных поручений для кошельков определенно довольно интересен. Я не знаю, могут ли какие-либо кошельки делать это прямо сейчас, но я не изучал этот вопрос слишком глубоко, так что это возможно. Мои первоначальные мысли заключаются в том, что я чувствую, что валидаторы, вероятно, не будут теми, кто делает MEV. Скорее всего, это будет внешний поиск. Так что если бы кошелек делал это, он бы подключился к какому-нибудь рынку или чему-то подобному, где он мог бы транслировать транзакции, как флэш-споты. Я также не думаю, что кошельки должны делать это, если честно. Это нарушает доверие между ними и пользователями.

Алехо: Я думаю, что аргумент заключается в том, что кто-то будет это делать, потому что он знает, что это проходит через него. Почему бы не сделать это прозрачным? Думаю, это аргумент в пользу флешпотов. Это происходит, так что давайте просто включим это в сеть и позволим эффективному рынку развиваться вокруг этого. Так что, возможно, мы разрешим этот тип MEV и не разрешим этот тип MEV. Это Дикий Запад. Как нам создать безопасный салон, где, если вас обгоняют, вы хотя бы получаете за это деньги? Ведь кто-то все равно это сделает, почему бы не позволить ковбоям, которые заботятся о ваших интересах, сделать это?

Роберт: Это справедливо. Думаю, я также не уверен, что важнее - поток заказов или заказы в блоке. Я думаю, что они оба важны, но я думаю, что большая часть вознаграждения в конечном итоге достанется самим валидаторам, потому что они контролируют как поток заказов, поскольку они получают все транзакции, так и упорядочение. Они контролируют, какой блок на самом деле будет произведен. Я думаю, что валидаторы хотели бы, чтобы они не играли на этом.  

Алехо: Проблема в том, что если все используют Metamask, а Metamask по умолчанию отправляет все это одним и тем же валидаторам, это похоже на конфликт интересов. Может быть, есть способ распознать, кому вы отправляете транзакции, но тогда транзакция будет проходить гораздо медленнее.

Роберт: Я просто думаю, что оптика потока платежных поручений, на Reddit по этому поводу огромный переполох. Я просто думаю, что это не лучшее решение. Я думаю, что это довольно рискованно с точки зрения того, как пользователи воспримут это.

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

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

Алехо: Круто. Давайте сменим тему. У нас есть много вопросов, которые поступили. Я не знаю, хватит ли у нас времени на все из них. Давайте дадим кому-нибудь высказаться.

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

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

Джефф - спикер: Я из Web3 Builders Alliance, и в настоящее время мы работаем на Cosmos. Мы переходим к сетям Move и языку интеллектуальных контрактов на основе Rust. Мы предлагаем когорту уровня Masters, не для новичков, для людей, которые хотят стать старшими разработчиками.

Алехо: Мы действительно будем тестировать Move VM на Cosmos в будущем. Мы форкнули Libra VM, сделали ее совместимой с Wassum и поиграли с Cosmos SDK. У нас также есть Polkadot Parachain. Мы, конечно, рады, что вы здесь, на Aptos, но скоро мы придем и в Cosmos. Но что касается темы быстрого продвижения и быстрой поломки, на самом деле из экосистемы Кусама/Полкадот я узнал, что вы можете тестировать, пока вы говорите всем, что все будет хаотично. Мне нравится идея иметь, возможно, две версии приложений. Одна версия неизменна, неизменяема, вы доверяете, что ни у кого нет к ней доступа в любой форме. Никто не может ее изменить. В ней может быть что-то не так, надеюсь, что нет, потому что она прошла через аудит, и это ваша версия, готовая к производству. Но как насчет развилки этой версии, которая может быть обновлена, и вы можете быстро поставлять вещи? Вы можете сказать всем: "Эй, эта штука, возможно, не прошла полный аудит, мы ее тестируем". Это позволило бы нам двигаться быстро, тестировать, экспериментировать, ломать, ломать не только код, но, возможно, даже теорию игры, лежащую в основе некоторых наших предположений. Так что интересно услышать ваши мысли по этому поводу.

Роберт: Это интересный дизайн. Меня в первую очередь беспокоит вопрос, как пользователи узнают, какой из них использовать? Я думаю, проблема в том, что пользователи не знают, как оценить эти риски. Даже в случае со смарт-контрактами очень сложно определить, какова вероятность взлома. Мы даже толком не знаем. Я думаю, что в данном случае, если у вас есть две версии одного и того же приложения, и одна из них более безопасна, а другая не так безопасна, я полагаю, что пользователи, готовые взять на себя больший риск, могут использовать постоянно поставляемую версию. Но я думаю, что в реальности, если бы любое из них было взломано, это все равно было бы своего рода PR-кризисом.

Алехо: В этом смысле это больше похоже на позиционирование, знаете, "this-thing-will-get-hacked.com" против "this-thing-is-not-going-to-get-hacked-(hopefully).com". Просто разместите повсюду огромные красные объявления об отказе от ответственности, в которых говорится: используйте на свой страх и риск, не вкладывайте больше денег, чем готовы потерять, и т.д.  

Джефф: Стимулируемая тестовая сеть - тоже хорошая модель. Если вы стимулируете людей участвовать в вашей тестовой сети и оставлять отзывы, а также вознаграждаете их полезными токенами, вы пополняете базу пользователей. Это все еще приносит пользу проектам, потому что даже если они хотят сделать использование тестнета геймифицированным, чтобы получить больше токенов, по крайней мере, они используют его, и все выигрывают. Вы получаете обратную связь, а они используют тестовую сеть. Их цель - ломать вещи. Они выигрывают больше жетонов в стимулируемой тестовой сети, пытаясь сломать ваш продукт. Вы подпитываете эмоциональные потребности пользователей. Чем больше красного цвета на экране с надписью "Не используйте это", тем больше полных дегенератов будут приходить и использовать это. Лучше просто сказать: "Приходи, используй и ломай, а мы дадим тебе несколько токенов".

Алехо: И вы даже можете назначить вознаграждение, например, "Эй, если ты сломаешь его, то получишь вот эту долю, верно?

Джефф: Абсолютно. Но дело в слове "щедрость", я имею в виду, что психологически, знаете, я произношу слово "щедрость". Мне интересно, сколько людей на этой конференции думают: "Ну, для этого нужно быть разработчиком. Вам не обязательно нужны только разработчики, которые приходят и пытаются сломать ваш продукт, но вы также хотите, чтобы обычные пользователи бессистемно использовали ваш продукт и пытались сломать его с точки зрения пользователя, а не с технической точки зрения.

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

Джефф: Есть несколько разных версий того, как это выглядит. И смотрите, нет никакой реальной ценности, потому что это токены testnet. Способ создания ценности - это когда кто-то присылает отзыв или "я сломал вашу штуку", а на выходе...

Алехо: Разница в том, что если я запущу его, допустим, на Aptos mainnet, а не на devnet, то люди на Aptos devnet не смогут спамить, потому что им нужны токены Aptos для отправки транзакций. Поэтому, допустим, DDoS-атака на ваш devnet в некоторой степени предотвратима. Люди просто запрашивают токены из крана, или вам нужно сделать KYC/AML, или что-то подобное, что очень обременительно и потенциально может иметь последствия для конфиденциальности. Как же нам запустить эту штуку в реальной среде, где есть защита от спама? Потенциально, именно здесь, я думаю, вам нужна какая-то форма реальной ценности, чтобы эти вещи обрели самостоятельную жизнь. Я думаю, это должно быть вживую, на природе. Вы не можете держать его в лаборатории, иначе вы не проверите все вещи, которые могут сломаться, и вы не получите выгоду от защиты от спама, если он будет жить в дикой природе. Извините, я перебил.

Джефф: Нет, вы в полном порядке! Для меня хороший вопрос ведет к инновациям. Я еще не обдумал то, что собираюсь сказать, но я имею в виду, что, возможно, вы играете с каким-то придуманным жетоном. Я знаю, что это полное кощунство, но просто используя его, вы набираете очки, которые потом можно обменять на реальные ценности. Например, вы запустили эту штуку в mainnet и можете получить средства на кран, но они ограничены, вы не можете получить их миллиард. Вы заходите и играете, получаете очки за игру и, достигнув определенного порога, получаете приз, который в определенный момент можно обменять на реальную стоимость. Это не привлечет ваших DeFi дегенов, потому что они не хотят играть в игры, но это привлечет достаточно людей, которые хотят играть, чтобы получить некоторую обратную связь, которую вы могли бы не получить в противном случае. Это проблема, которая может сработать.

Роберт: Я думаю, что потенциально проблема может быть связана с тем, может ли это быть жизнеспособным. Если у вас есть токен, который имеет реальную ценность в реальном мире просто при его использовании, возможно, можно как-то подделать это использование.

Алехо: Я думаю, что вы просто хотите предотвратить спам ботами, какой бы механизм вы не использовали. Защита от спама - это реальная мировая ценность. Она стоит вам денег. Поэтому я думаю, что идея о том, что токены имеют реальную мировую ценность, очевидно, более философская. Допустим, мы создаем клон биткоина и просто выпускаем его в мир. Какова реальная мировая ценность? Если кто-то может атаковать его спамом, то это, вероятно, не является реальной мировой ценностью. Но если кому-то нужны токены Aptos для спам-атаки, то вы, по крайней мере, знаете, что начинаете привязывать к нему какую-то реальную ценность. Допустим, я бот, я потратил 1000 долларов на добычу этих монет, и теперь эта штука стоит 1000 долларов. Опять же, вы запускаете это в мир и смотрите, что произойдет, тестируете. Я думаю, вам нужно связать это с вознаграждениями за ошибки и уязвимости.

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

Алехо: Я думаю, что один из примеров использования, о котором я думаю, заключается в следующем: Допустим, Aave работает над v7, и они думают о какой-то совершенно новой инновации, которую еще никто не делал в мире. Они могут получить 10 миллионов аудитов, но это нужно для того, чтобы кто-то понял, что произойдет, если я сделаю этот кредит с этим токеном, а затем перенесу его с другого моста. Возможно, произойдет какая-то странная теория игр или экономическая атака, которой даже нет в коде. Как они могут проверить это, не имея реальной среды? Я просто думаю, если они собираются опубликовать версию и пытаются донести ее до людей, может быть, есть способ позволить людям протестировать ее вживую, на производстве, без того, чтобы это была производственная версия. Есть ли способ сделать это безопасно?

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

Алехо: Или даже эксперты, верно? Я бы пригласил тебя, Роберт, и всех остальных, кто думает, что сможет взломать систему, потому что в конце дня, если вы это сделаете, должно быть вознаграждение или награда для хакеров в белой шляпе. И это может быть осязаемая, реальная ценность, которая к этому прилагается. Типа: "Хорошо, если вы его сломаете, то получите вот такую цену". Я думаю, Джефф говорил об этом. Я думаю, это хорошая идея.

Роберт: Да, я тоже думаю, что это может сработать. Есть множество различных способов стимулировать сообщества рассматривать контракты или проекты.

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

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

Я думаю, что все это будет отражено в отчетах, а также, если возникнут проблемы, мы будем тесно сотрудничать с Робертом, чтобы устранить их в режиме реального времени. Если есть уязвимости, именно поэтому мы работаем с такими людьми, как Роберт, чтобы помочь нам найти их и устранить. Мы публикуем публичный отчет, с которым может ознакомиться любой человек, чтобы он мог чувствовать себя в безопасности при использовании продуктов. Это часть процесса запуска таких продуктов, особенно в совершенно новой экосистеме. Вы должны быть очень осторожны. Кроме того, у нас избыток аудиторов, поэтому мы проводим несколько проверок. Извините, Роберт, надеюсь, это не жульничество. Но вы, наверное, согласитесь, что это хорошо, что у нас есть избыточность.

Когда мы запустим компанию, мы будем готовы к первому дню благодаря тому, что Роберт поможет нам провести эти аудиты. Мы также будем проводить много тестов на проникновение в кошелек, как мы уже говорили, это будет очень важно. Очень скоро вы сможете использовать эти продукты в mainnet, когда Aptos начнет работать. Сейчас все работает в devnet. Зайдите на сайт liquidswap.com и протестируйте его.

Мне интересно услышать ваши мысли, Роберт, о том, как сообщество может быть связано с безопасностью.

Роберт: Я думаю, что удержание пользователей - это одна из самых сложных вещей. Я думаю, что для dApps, но особенно для кошельков, вы, по сути, монетизируете целевые страницы пользователей. Вот почему Metamask может взимать относительно высокую плату и зарабатывать таким образом кучу денег. Я думаю, что в сфере безопасности мы не работаем напрямую с сообществом, но я думаю, что мы работаем с протоколами, которые очень заботятся о своем сообществе, и мы стараемся быть настолько активными в сообществе, насколько это возможно, поэтому мы, например, находимся в этом пространстве Twitter. Хорошо слышать отзывы не только от протоколов, но и от пользователей и пытаться понять, как мы, как аудиторская фирма, можем наилучшим образом ответить пользователям. Ведь в конечном итоге мы все служим пользователям и стараемся сделать все возможное, чтобы это место стало лучше для всех.

Алехо: Да. И если мы будем чувствовать себя в безопасности, я думаю, люди захотят остаться здесь. Это, наверное, приоритет номер один, верно? Чтобы люди чувствовали себя в безопасности.

Роберт: Именно, я думаю, что в последнее время криптовалюты привлекают много негативного внимания из-за всех проблем с безопасностью. Но да, мы заботимся о том, чтобы протоколы, с которыми мы работаем, никогда с ними не столкнулись. Это цель.

Думаю, с моей стороны это все. Было очень интересно, спасибо за приглашение. Было приятно пообщаться со всеми на тему безопасности.

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