Tornado Cash – самое известное (и уже работающее) решение для анонимизации платежей на блокчейне Ethereum. Мы пригласили в гости его создателей Романа Сторма, Романа Семенова и Алексея Перцева и обсудили безопасность подобных продуктов, их устройство и разницу в подходах для разных блокчейнов.
- 1:30 Благодарим наших патронов и спонсоров: Solana, HodlHodl и Zerion!
- 4:11 Как гости попали в команду Tornado Cash?
- 7:21 Что такое миксер?
- 12:59 Насколько эффективны миксеры на Bitcoin?
- 14:46 Можно ли сделать на Ethereum эффективный миксер без использования Zero Knowledge?
- 17:20 Актуальна ли для Ethereum проблема «грязных» монет из миксеров?
- 22:38 Как работает Tornado Cash?
- 26:58 А может ли эта система скейлиться?
- 29:30 Как работает SNARK?
- 33:53 Почему именно SNARK, а не STARK например?
- 35:05 Что такое и зачем нужен Trusted Setup?
- 41:25 Почему не использовать Trusted Setup от ZCash?
- 44:13 Сколько поучаствовало людей?
- 46:22 Кто такие релееры?
- 50:36 Обновляемы ли контракты Tornado Cash?
- 54:46 Не является ли фронтенд точкой централизации?
- 56:20 Кого конкретно в себя включает анонимити сет и как его увеличить?
- 1:01:11 Какие правила безопасности необходимо соблюдать при использовании Tornado Cash?
- 1:03:01 Как обеспечить сетевую безопасность, если метамаск посылает все запросы на инфуру?
- 1:04:23 Можно ли пользоваться Tornado.cash через Tor?
- 1:08:30 Какие еще есть решения для приватности в крипте?
- 1:12:38 Гранты и проблемы с монетизацией Tornado Cash.
- 1:18:24 Ближайшие планы.
Ссылки:
Спасибо нашим спонсорам:
- Подкаст выходит при поддержке Zerion – понятного интерфейса к DeFi-протоколам.
- Подкаст выходит при поддержке HodlHodl – площадки для покупки и продажи биткоинов без верификации. Зарегистрируйтесь и получите скидку на комиссию!
- Подкаст выходит при поддержке Solana – быстрого блокчейна без шардинга. Подробности на solana.com и в телеграме @solanarus.
Поддержите подкаст! - Bitcoin: bc1qec856uhwuguhnn28r54tlkrh3dh95ctajvpjaf
- Patreon: https://www.patreon.com/basicblockradio/overview
Начало записи
(00:00:00)
Роман Сторм: Мы сами не знаем, почему до сих пор у нас нет гранта от Ethereum Foundation.
Сергей Тихомиров: Ох, сложно как-то это всё.
Александр Селезнев: Мне вообще так нравится ваш интерфейс.
Роман Семенов: Groth16 система преобразует ее к каким-то матрицам и многочленам.
Сергей Тихомиров: Мне кажется, я уже запутался сам. Вот давайте мы как-то выплывем.
Роман Сторм: Ну и небольшой спойлер, наверное, такой алерт.
Роман Семенов: Tornado Cash строго лучше, чем CoinJoin.
Александр Селезнев: Привет! С вами подкаст «Базовый Блок» – подкаст про блокчейн. Это выпуск №125. У микрофона сегодня Сергей Тихомиров.
Сергей Тихомиров: Всем привет!
Александр Селезнев: И Александр Селезнёв. Это я. Как мы знаем, обеспечение собственной приватности и анонимности – это одна из краеугольных проблем, которые встают сегодня перед любым человеком, который соприкасается с публичными блокчейн-решениями. И сегодня мы пригласили к нам в гости одну из самых нашумевших в последнее время команд, которые работают над этими проблемами. Это команда проекта Tornado Cash. Это Роман Сторм, Роман Семенов и Алексей Перцев.
Можете сказать привет в порядке представления.
Роман Сторм: Здравствуйте, ребята. Я Роман Сторм. Мы вот с ребятами построили Tornado Cash. Рад приветствовать вас всех на этом подкасте.
Роман Семенов: Всем привет!
Алексей Перцев: Всем привет!
Александр Селезнев: Сегодня мы поговорим, конечно же, в первую очередь о Tornado Cash, но я надеюсь, также обсудим историю и текущее положение дел с анонимностью в блокчейне. Но прежде чем мы начнём, я хотел бы потратить немножко времени на то, чтобы поблагодарить тех, кто поддерживает наш подкаст. И в первую очередь я хочу поблагодарить наших патронов на «Патреоне». У нас появляются новые патроны, несмотря на эти непростые времена, и нельзя просто описать, сколько теплых чувств я испытываю каждый раз, когда я вижу оповещение на почте, что у нас появился новый патрон.
Ребят, спасибо вам большое за поддержку. Если бы не вы, то нам было бы очень тяжеловато. Если хотите нас поддержать, проходите на patreon.com/basicbloсkradio. И можете найти эту ссылку в описании.
Также я хотел бы сказать спасибо нашим спонсорам. Первый наш спонсор – это Solana. Это блокчейн с невероятной скоростью 60 транзакций в секунду. В выпуске ББ-112 мы очень въедливо обсуждали, как это может быть возможно. Послушайте, если вам интересно. Проект сейчас развивается в русскоязычном комьюнити, у них есть группа в Telegram (@solanarus), в Вконтакте у них есть даже группа. Ссылки найдете в описании. Посмотрите, если интересно.
Также спасибо компании HodlHodl. HodlHodl – наши старые друзья. Это самый быстрый и безопасный способ купить и продать биткоины без KYC. Регистрируйтесь на HodlHodl по нашей ссылке в описании, по реферальной нашей ссылочке, и у вас будет супернизкая комиссия, просто невероятно низкая, это будет очень круто.
И большое спасибо за поддержку компании Zerion. Zerion – это команда, которая делает простой интерфейс к экосистеме DeFi, и также она делает инструменты для разработчиков под DeFi. И сегодня я хотел бы чуть-чуть, наверное, побольше сказать про их продукт DeFi SDK. Ну, точно так же, как всем известно, что исчезающее меньшинство людей в DeFi пользуются больше чем одним протоколом из-за того, что в каждом протоколе нужно преодолевать некий барьер адаптации, разработчики новых Dapp’ов и новых DeFi-проектов, тоже им приходится тратить много времени на интеграцию каждого нового проекта. И вот когда-то Zerion на этих интеграциях, понятное дело, съели собаку, и вот они решили облегчить остальным разработчикам эту участь и выложили в открытый доступ всю библиотеку смарт-контрактов DeFi SDK. Это библиотека для взаимодействия с многими DeFi-протоколами через единую точку входа, чтобы разок интегрироваться с этой библиотекой, а не интегрироваться каждый раз с каждым новым протоколом. В общем, если вы разработчик, разрабатываете что-то под DeFi, то проходите по ссылке в описании – сэкономите себе кучу времени и сил.
Большое спасибо еще раз всем нашим спонсорам. Ну что же, я думаю, начнём. Наверное, первый вопрос будет абсолютно традиционный, без изменений (уже больше сотни выпусков). Ребята, расскажите, пожалуйста, как вы попали даже не просто в блокчейн, а как вы попали вот в эту команду, как вас дорожка привела?
Роман Сторм: Да, я могу поделиться этой историей. У нас у всех есть хороший, серьёзный инженерский background в традиционных технологических сферах, в банковских, в penetration testing, в разработке. Но вот мы где-то с 2018 года основали компанию под названием Peppersec.com, где мы занимаемся разработкой смарт-контрактов, Security аудитами и так далее.
(00:05:00)
И также мы очень любили всегда участвовать в хакатонах, и я также всем нашим слушателям рекомендую. Все, кто не знает, чем заняться или какую-то новую идею сделать – участвуйте в хакатонах, ребята. Это прекрасный способ проверить свои скиллы и также познакомиться с многими разными новыми людьми. Вот таким образом мы, например, познакомились с Романом Семеновым. С Алексеем мы встретились на одном из аудитов. Когда я когда-то работал в POA Network, Алексей, собственно, занимался просто security-аудитами.
Ну и вот, мы вот как-то… Синергия нашла нас, друг друга.
Роман Семенов: Я до блокчейна делал всякие разные стартапы из российских (частично известно, может, RedHelper, livechat). В блокчейн попал года 2 назад. Меня позвали ребята делать имплементацию плазмы (это layer 2 для Ethereum. Сейчас они, в общем, называются Matter Labs, но тогда все были под другим брендом. Потом, в итоге, я познакомился с Ромой и Лёшей на хакатоне в Нью-Йорке (Peppersec), и потом мы сделали пару проектов мелких, и в какой-то момент решили делать Tornado Cash (приватность).
Background у меня в блокчейне в основном research по layer 2, SNARK и всё такое.
Алексей Перцев: Я стартовал свою карьеру с аудитов, с penetration testing. В основном занимались аудитами безопасности банков (компания Digital Security). Но в какой-то момент туда же начали приходить заказы аудита смарт-контрактов, и так я стал все больше и больше уделять времени именно Ethereum. В какой-то момент решил начать свою собственную практику, именно делать аудиты. И так мы, собственно, познакомились с Романом, и с этого начался путь в блокчейне. Больше всего меня интересует разработка именно и безопасность смарт-контрактов.
Александр Селезнев: Понятно. Спасибо. Ну, теперь, когда мы разобрались с историей лично вашей, я предлагаю перейти к истории приватности, истории миксеров вообще на блокчейне. Давайте начнём вот с простого вопроса. Допустим, нас слушает много людей, которые первые сейчас включили наш этот выпуск, впервые слышат слово «миксер». Расскажите, что это такое вообще?
Роман Сторм: Ну, хорошо. Мы вообще любим называть это privacy solution. Миксер – это как-то такое немножко не совсем, наверное, приятное слово для многих регуляторов. Что такое privacy solution? Как мы знаем, стандартно во многих публичных блокчейнах все транзакции, они публичные, то есть у вас нет абсолютно никакой приватности, когда вы используете биткоин или эфириум и так далее. Соответственно, чтобы вам как-то обфусцировать вашу историю транзакций, вам нужно применить какой-либо из privacy solutions. Например, одно из… вот самое популярное в Bitcoin решение называется CoinJoin, и одной из имплементаций этого протокола является Wasabi-кошелёк и Samourai. Что они делают? Так как в Bitcoin есть система UTXO (Unspent Transaction Output) – это то, как управляются балансы и аккаунты вообще в сети Bitcoin – они, собственно, как бы замешивают исходящие и входящие балансы, так скажем. Всем, кому интересно, можете просто пройти ниже по ссылке, посмотреть про Wasabi или про Samourai, что это такое и как это работает. Так как мы очень любим Ethereum-блокчейн, нам очень он симпатичен, нам нравятся смарт-контракты, поэтому мы разработали Tornado Cash, который является privacy solution для Ethereum-блокчейна.
В Ethereum-блокчейне, как мы знаем, нет модели UTXO по стандарту. Там так называемый есть account-based model. Что это означает? То, что у каждого адреса есть, собственно, свой аккаунт и вот на нем как базе данных, собственно, есть баланс ваших эфиров. И таким образом, есть ещё очень удобный язык для написания смарт-контрактов – Solidity. Ну, есть ещё и другие, но Solidity – самый популярный. И на Solidity вы можете, собственно, любой смарт-контракт, который будет управляться какой-либо логикой. Одно из таких применений: вы можете написать, есть поддержка кривых по SNARK уже на Ethereum, уже нативно.
(00:10:04)
Это уже есть. Соответственно, всё, что мы сделали, написали… Ну как, это, конечно, была очень огромная работа, и к этому эфиру само Ethereum-комьюнити долго шло. Мы написали смарт-контракт, который может проверифицировать, что вот я сделал депозит в этот смарт-контракт, а потом я сделал вывод из этого смарт-контракта, но при том, что когда я делаю вывод из этого смарт-контракта, я не показываю, какой депозит я использовал, с какого адреса я сделал депозит. Таким образом, что является здесь Zero Knowledge Proof? Вы можете доказать смарт-контракту, что вот у меня есть депозит в этом смарт-контракте, не раскрывая, собственно, сам депозит. В этом и заключается такая вот магия Zero Knowledge Proofs.
Роман Семенов: Хотелось бы в целом про приватность немножко сказать, что в целом и наличие приватности для блокчейна, оно очень критически важно, если мы хотим широкий adoption, если мы хотим, чтобы много новых пользователей приходило и пользовалось в какой-то повседневной, возможно, жизни блокчейном, в особенности бизнесы. Потому что для многих пользователей не очень было бы комфортно, скажем, раскрывать данные своего банковского счёта публично, а при этом на блокчейне всё именно так и есть, что вся финансовая история каждого пользователя, она публична. А в особенности для бизнесов, раскрывать своих клиентов, финансовые потоки, откуда сколько прибыли бизнес получил и кому там из сотрудников сколько он платит зарплаты, это неприемлемо. Соответственно, в какой-то форме приватность обязательно должна быть на блокчейне.
Алексей Перцев: Также, наверное, хотел бы подчеркнуть принципиальную разницу между… что является традиционным представлением у людей миксера и то, что есть Tornado Cash. В отличие от традиционных миксеров, которые просто обфуцируют, по сути, граф транзакции, то есть они запутывают логику, но всё ещё там какие-то анализом можно установить, как прошли, собственно, деньги – от депозита и снятия дальнейшего. В отличие от этой схемы, Tornado Cash полностью рвет связь между адресами депозита и вывода.
Роман Сторм: С небольшой поправкой: если вы соблюдаете определенные правила безопасности. Потому что если вы, скажем, будете неаккуратны с тем, как вы используете Tornado Cash, вы всё ещё можете на самом деле раскрыться. Поэтому у нас есть для этого ссылочка (privacy tips) на нашем сайте, где мы четко описываем, какие правила нужно соблюдать, чтобы сохранять анонимность.
Александр Селезнев: Ну, давайте мы это еще обсудим обязательно. Но мне хотелось бы сейчас сделать ещё небольшой шаг назад. Мы вот сейчас уже упомянули Wasabi, упомянули CoinJoin. Насколько на практике они действительно работают? Насколько они спасают человека? Или это вот такая припарка чисто для самоуспокоения, а Chainalysis какой-нибудь без труда всё это распутает?
Роман Семенов: В Wasabi и в остальных подобных кошельках тоже очень важно соблюдать различные правила, не светить свой IP-адрес и грамотно потом менеджерить эти UTXO, которые получены на выходе, чтобы их нельзя было друг с другом как-то связать. И если все эти правила хорошо соблюдать, то Chainalysis очень сложно будет проследить какую-то взаимосвязь. То есть они работают, если грамотно их использовать.
Роман Сторм: И также мы уже знаем, как один из недавних был AMA на Reddit (AMA – это такой формат, когда любой участник задает вопрос), и там был один из работников Chainalysis, он, скажем так, анонимно вышел (скорее всего, его после этого уволили, но тем не менее), он устроил публичный AMA, где любой мог задать ему вопрос: «Ребята, как у вас дела и что такое?». Вы можете найти эту информацию в Интернете. И там его конкретно спросили: «Что вам больше всего сложно?», и вот как раз-таки работник Chainalysis сказал, что они как бы любят Wasabi-кошелек, но с точки зрения бизнеса они его не любят, потому что им действительно сложно работать с этими протоколами, так как они действительно могут предоставлять решения рынку.
Александр Селезнев: Вот интересно. Такой сразу вопрос. Возможно ли на Ethereum тоже сделать такого типа миксеры без Zero Knowledge, но которые существенно затрудняют работу тому, кто хочет отследить мои транзакции?
(00:15:02)
Или разница между UTXO-моделью и account-based моделью в этом смысле критична?
Роман Сторм: Ну, я вам отвечу, наверное, не совсем прямолинейно. В принципе, да, можно и так делают все центральные биржи, потому что любая центральная биржа также является миксером, потому что с публичной точки зрения невозможно увидеть, кто, какие адреса уже баланс меняют, потому что всё это складывается в какой-то MySQL базе данных, и народ там спокойненько всё это мешает. Но в этом есть фундаментальное отличие традиционных миксеров и нетрадиционных. Традиционные – это кастодиан-миксеры. Что значит кастодиан? То, что когда вы какой-то миксер-кастодиан как центральная биржа отдаёте, это уже не ваши деньги и приватный ключ, вы на какой-то чей-то приватный ключ отправили деньги. Всё, это не ваши деньги, и там они, соответственно, уже могут и помешать, и сделать всё что угодно. А не кастодиальные миксеры, так как являются Tornado Cash, ZCash, Monero, Wasabi, фишка в том, что несмотря на то, что вы используете этот solution, вы никогда не расстаетесь со своими средствами. Они всегда будут принадлежать вам, и вы можете иметь к ним доступ, и разработчики этого протокола никаким образом не имеют доступ к вашим деньгам. В этом есть фундаментальное отличие и то, за что, собственно, наверное, весь блокчейн-хайп происходит с 2009 года, в том, чтобы построить системы децентрализованные и trustless.
Роман Семенов: Ещё более конкретно добавил бы к вопросу на счет CoinJoin на Ethereum. В принципе, эту систему, конечно же, можно перенести на Ethereum, но модель Tornado Cash, она как бы строго лучше, чем CoinJoin. CoinJoin – это одно из самых лучших решений, доступных на Bitcoin, но Bitcoin обладает очень ограниченной способностью. Там нельзя запрограммировать сложные вещи, в том числе SNARK. Соответственно, для Bitcoin это решение хорошее, но на Ethereum можно сделать гораздо лучше. Например, Tornado Cash. Поэтому смысла переносить CoinJoin-решение нет, потому что у него будет гораздо хуже свойство приватности.
Александр Селезнев: Раз уж мы уже упомянули биржи, вот такой вопрос. На Bitcoin, я вот там уже много раз слышал эту проблему, что люди там очень осторожны, покупая… многие люди, кто этим промышленно занимается, очень осторожно покупают биткоины, чтобы они не были, не дай Бог, из миксеров. Желательно, чтобы биткоин был прямо вот свеженький от майнера, и даже они стоят по-разному, там есть даже какая-то разница в стоимости между свежим биткоином и биткоином с историей, как раз чтобы избежать подобных проблем. Может ли такая же ситуация, и происходит ли она сейчас, появится в Ethereum?
Роман Сторм: Конечно же, может. Смотрите, что делают биржи. Биржи подчиняются определенным законодательствам и законам, как Anti-money laundering, то есть закон против отмывания денег. И этот закон гласит, что вы должны знать ваших пользователей и знать, откуда деньги у этого пользователя. И соответственно, у нас Tornado Cash, мы считаем, что он как раз-таки хорошо подходит тоже и для таких решений, потому что у вас как бы ваша анонимность, она по вашему выбору происходит. То есть, что я имею в виду. Вот если я использовал Tornado Cash, у меня сохраняется некий так называемый private note от Tornado Cash, и этот private note дает мне возможность доказать, в том числе и бирже, происхождение моих денег. То есть, я могу прийти на Tornado Cash, у нас есть ссылочка, называется compliance tool, где я могу вставить ноду, и он мне сгенерирует удобный report, который я могу отправить этой бирже и доказать происхождение своих средств. Такую же схему использует ZCash. У них есть, называется Viewer key, и они тоже недавно сделали блог-пост о том, что ZCash, с точки зрения регуляции он compliant solution.
Александр Селезнев: Понятно. То есть, такая проблема теоретически возможна, но у вас она преодолена специальным…
Роман Сторм: Есть, конечно же, ситуации, которые, допустим, если я, скажем, какой-то предприниматель, который принимает платежи в криптовалюте, и кто-то мне заплатил из кошелька Tornado Cash, и у меня нет вот этой приватной ноты, чтобы доказать, откуда на самом деле была депозит-транзакция, тем не менее, всё равно вы ведете бизнес, так же как и любой другой традиционный бизнес, у вас там есть, наверное, какие-то инвойсы и так далее, и вы интерактируете с каким-то конкретным бизнесом, с каким-то конкретным человеком. Несмотря на то, что он заплатил вам через Tornado Cash, я думаю, у вас всё ещё будут другие способы доказательств, проще говоря, метаданные об этом пользователе, которые вы можете предоставить любому другому, правоохранительным органам или кому.
(00:20:16)
Вам нужно, чтобы доказать, откуда у вас деньги. Собственно, тут блокчейн не новость. Это традиционный аккаунтинг, который был еще и до блокчейна.
Роман Семенов: Я бы еще сказал, что Ethereum подвержен этой проблеме чуть в меньшей степени, чем Bitcoin, потому что на Ethereum есть аккаунты. И представим ситуацию, когда я веду какой-то бизнес, у меня есть 100 эфиров на кошельке, и мне заплатили еще один эфир из Tornado. У меня, получается, на аккаунте 101 эфир, один из которых из Tornado пришел, но они все выходят смешаны. Соответственно, если я буду заводить их на биржу, скорее всего, это не поднимет никаких красных флагов, потому что доля вот этих, возможно, рисованных средств в моих общих средствах очень маленькая. Мы уже несколько раз общались с различными lawyer-регуляторами, и в основном они говорят, что все эти AML-политики (anti-money laundering), они базируются на рисках. То есть, каждый случай рассматривается отдельно, в зависимости от всех общих параметров. Скажем, если кто-то заводит один или 10 эфиров на биржу, скорее всего, вопросов никаких не будет, а вопросы будут возникать, если кто-то внезапно миллион долларов, скажем, заведет, и тогда уже рискованность этой операции сильно больше, и будут различные красные флаги.
Сергей Тихомиров: Я здесь хотел задать уточняющий вопрос по поводу того, что эфиры смешиваются в Ethereum-адресах. А разве в Bitcoin не такая же картина, где у меня может быть UTXO из миксера, другое UTXO – из какого-то чистого источника, и я их смешиваю в одной транзакции? Разве это не то же самое?
Роман Семенов: Ну, их можно смешать, но зачастую они не смешиваются. Скажем, если у меня было 100 битков, я получил еще один, а потом, скажем, три биткоина кому-то плачу, и в этих трех биткоинах именно содержится вот этот один, который я получил откуда-то. То есть в Ethereum, если я буду платить часть из этих средств, они, получается, уже из общего мешка берутся. А когда я плачу в Bitcoin, берутся конкретные UTXO какие-то. Я их могу при желании смешать все в один UTXO, сделать мердж, но, как правило, кошельки это редко делают автоматически, они просто набирают для каждого платежа какой-то массив из UTXO существующих.
Александр Селезнев: Хорошо. Какой-то необходимый background мы уже набрали. Я думаю, теперь можно перейти к тому, как именно устроен Tornado Cash. Вот уже мы немножко этой темы коснулись. Можете рассказать, как устроена работа Tornado Cash, может быть, с точки зрения смарт-контракта, например, сначала, с точки зрения блокчейна? Ну, то есть не с точки зрения User eXperience, а с точки зрения технологий, что происходит?
Алексей Перцев: Окей. Существуют смарт-контракт Tornado Cash, который принимает специально сформированные депозиты. Помимо Ethereum или ERC-20 токена, юзер должен предоставить некий комитмент – это хэш от некоторой приватной информации, с помощью которого он позже будет списывать эти деньги из смарт-контракта. После этого проходит какой-то промежуток времени, достаточно большой (чем больше, тем лучше), набираются еще другие депозиты, от других пользователей, и в какой-то момент времени пользователь может, опять же, прийти в смарт-контракт и, предоставив специально сформированный пруф (доказательство), снять свои деньги. О чем говорит это доказательство? Оно говорит лишь о том, что у меня есть какой-то из депозитов, когда-то сделанных в Tornado Cash, без раскрытия того, какой конкретно депозит был сделан. Таким образом, рвется связь между депозитом и снятием. Также снятие происходит на какой-то адрес, на котором никогда не было никаких средств. Получается, у вас совершенно новый адрес с имеющимся эфиром или токеном. Если коротко, то так.
Сергей Тихомиров: У меня по архитектуре еще тогда вопрос. С точки зрения опять-таки смарт-контракта что именно там хранится? То есть, если я, допустим, хочу положить свой, скажем, один эфир в Tornado, я отправляю транзакцию, которая имеет value 1 ETH плюс хэш моего секрета. Что происходит с этим значением потом: оно сохраняется прямо в смарт-контракте или оно как-то агрегируетя? Я просто пытаюсь понять, это хранится все в какой-то структуре данных, в каком-то массиве в смарт-контракте, или это необязательно должно хранится в виде списка этих хэшей?
Алексей Перцев: Это хранится в виде merkle tree (дерева). Все эти комитменты добавляют… Каждый новый комитмент добавляется в это дерево и там, собственно, и хранится.
(00:25:04)
И позже мы предоставляем merkle path приватно как доказательство того, что у нас есть там депозит.
Роман Семенов: Для полноты картины я бы еще немножко описал, как мы защищаемся от даблспендов, как сделать так, чтобы если пользователь предоставляет еще раз merkle proof на тот же самый депозит, который он уже снял, как мы не даем ему снять еще раз, если мы в первый раз не знаем, какой депозит он тратил. Могу рассказать, как это работает.
Когда пользователь делает депозит, он генерирует массив каких-то случайных 62 байта, и когда он делает депозит, от этого массива берется хэш, и этот хэш называется комитмент, кладется в дерево. И у контракта есть еще одна структура данных – массив так называемых нулифаеров. Нулифаер – это хэш, грубо говоря, от половины этих приватных байт, то есть у нас хэш от 62 байт – это комитмент, и хэш от первых 31 байта – это нулифаер. То есть, когда мы видим два этих хэша, они между собой вроде как никак не связаны, то есть если внешний наблюдатель увидит просто два хэша, он не поймет, что они связаны между собой, но при этом у каждого массива этих приватных байт у него однозначно определяется вот этот нулифаер. Соответственно, когда юзер предоставляет доказательства для какого-то депозита, что он есть в merkle-дереве наших депозитов, он заодно еще публикует этот нулифаер (хэш половины этих депозитов), и смарт-контракт знает, что если он этого нулифаера еще не видел, это значит, что для этого депозита, но он не знает какого, снятие еще не происходило, и можно спокойно выдавать деньги. Если ему дают нулифаер, который он уже видел, это означает, что человек предоставил доказательства для какого-то депозита, который уже был снят. Соответственно, в смарт-контракте получается две структуры у нас – дерево комитментов и массив, простой hashmap вот этих нулифаеров.
Сергей Тихомиров: Мне хотелось бы разобраться на самом деле с точки зрения хранения именно данных, где именно эти деревья хранятся, потому что у меня возникают такие мысли, несколько скептические, относительно того, как эта система может скейлиться. Потому что если у нас накапливаются эти комитменты, если у нас накапливаются нулифаеры, то нет ли такого, что хранилище смарт-контракта раздувается, и в какой-то момент это станет не viable. Или эти данные не хранятся ончейн, а хранятся где-то офчейн, а ончейн хранится только какой-нибудь merkle root. Вот где именно хранятся эти данные?
Роман Сторм: Все данные хранятся в ончейн, в смарт-контракте. И при деплойменте смарт-контракта вы можете указывать высоту дерева, с какой высотой вы хотите хранить данные. То есть, при данной имплементации Tornado Cash мы выбрали высоту 20. Соответственно, около миллиона листьев дерева может храниться ончейн.
Сергей Тихомиров: А что произойдет, когда это количество будет превышено?
Роман Сторм: Ну, задеплоим новый контракт.
Роман Семенов: Нельзя будет сделать новый депозит, можно будет снимать существующие депозиты. И мы просто должны будем задеплоить, видимо, с более глубоким уже деревом. Пока что у нас порядка тысяч депозитов есть, то есть до миллиона пока что дойдет очень нескоро. И каждый раз, когда пользователь делает депозит или снятие, каждый пользователь платит за то, чтобы добавить одну ячейку в storage, то есть эта стоимость за storage, она как бы распределена в виде газа на всех пользователей, и здесь не возникает проблем именно c scalability.
Еще бы один момент добавил про дерево депозитов. Строго говоря, для депозитов можно хранить только в merkle root и просто на каждый депозит эмитить ивент, какой лист был добавлен, чтобы дерево можно было воссоздать у клиента, просканировав эти ивенты. Но в нашей имплементации мы храним массив депозитов, для того чтобы сделать sanity check, чтобы убедиться, что пользователь случайно не делает депозит на комитмент, который уже был сделан. Но сделан массив комитментов не для того, чтобы защитить от того, что у какого-то другого пользователя будет такой же, потому что комитменты – это хэш случайного большого числа. Вероятность того, что они у разных пользователей совпадут, почти нулевая. Это, скорее, сделано от того, что если у пользователя неправильный клиент, который случайно взял и переиспользовал уже существующий комитмент, чтобы он не испортил, не потерял деньги таким образом, то есть другой пользователь не может помешать в данном случае.
Сергей Тихомиров: Давайте еще уточним, следующий вопрос. Когда вы говорите про то, что пользователь предъявляет доказательство, что его комитмент входит в Merkle-дерево, правильно ли я понимаю, давайте проясним этот вопрос, что здесь как раз то место, где и вступает в игру магия Zero Knowledge Proofs, потому что наивная имплементация говорит, что как бы я даю свой хэш, я предоставляю листья, точнее предоставляю узлы промежуточные Merkle-дерева, которые ведут от моего хэша к корню, и смарт-контракт просчитывает все хэши и удостоверяется, что они в конце концов совпадут.
(00:30:04)
Правильно ли я понимаю, что именно эту процедуру мы заменяем Zero Knowledge Proof, для того чтобы я мог это сделать, не раскрывая на самом деле, какой я лист имею в виду?
Роман Семенов: Но я могу тогда последовательно рассказать примерно, как SNARK работает. На вход SNARK публично подается root Merkle-дерева, и смарт-контракт потом проверит, что этот root совпадает с тем, что у него в storage есть, он в storage хранит последние 100 root’ов. История root’ов нужна для того, чтобы если я сгенерировал proof, и до того, как я успел его засабмитить, кто-то еще сделал один депозит, дерево изменится, root изменится, но для снятия это ничего страшного, если я какой-то более менее старый root предоставляю. Соответственно, подается публично merkle root, приватно подается путь до листа соответствующего (merkle pass), и SNARK проверит, что merkle pass корректный. Подается на вход исходная нота (вот эти исходные приватные данные), и SNARK проверяет, что хэш этих данных соответствует комитменту, то есть хэшу листа (хэш комитмента является листом Merkle-дерева). И также он считает хэш нулифаера, то есть первой половины байт этого комитмента, и публикует тоже этот хэш нулифаера, то есть SNARK проверяет, что этот хэш нулифаера был посчитан корректно.
Сергей Тихомиров: Когда ты говоришь «подает приватно», я правильно это понимаю, что это происходит на моей машине локально, то есть мой локальный генератор пруфов обрабатывает эти аргументы. Моя-то машина знает, какой я на самом деле хочу доказать, просто в сеть это не попадает в итоге.
Роман Семенов: Да, приватные данные не выходят за пределы пользовательской машины.
Сергей Тихомиров: У меня еще такой есть вопрос касательно безопасности, а именно касательно того вопроса, что я должен сгенерировать безопасно случайное число, его прохэшировать и далее то, что вы описали. Я вспомнил, давным-давно я имел опыт генерации бумажных биткоин-кошельков (может быть, помните, была такая фишка). Сейчас они уже считаются небезопасными, я даже не помню точно, почему, но не делать лучше так. Но там был сайт, который генерировал, и на сайте было написано красными буквами, что не нужно запускать эту процедуру прямо на сайте, а вы скачайте JavaScript, отключитесь от Интернета и сгенерируйте кошелек, его распечатайте на локальном принтере, а потом только подключитесь к Интернету, чтобы ваши секретные данные не утекли.
Как эту процедуру можно сравнить с тем, что происходит при пользовании Tornado, то есть когда я генерирую случайный секрет, где он на самом деле генерируется? Если он генерируется в браузере, то нет ли опасности, что браузер куда-то его утечет к вам или куда-то третьей какой-нибудь стороне?
Алексей Перцев: Да, он генерируется конкретно браузером. И более того, после того, как он был сгенерирован, мы предоставляем пользователю возможность сохранить этот секрет локально куда-то еще (записать на бумажку и так далее), после чего он дополнительно сохраняется в local storage, откуда он тоже может быть удален. Делается это просто на случай того, что все мы люди, и гораздо более вероятна ситуация, что человек просто потеряет эту ноту секретную, с помощью которой он будет списывать деньги, нежели он имеет скомпроментированное устройство, с которого он делает депозит. И это касается только пользователей, которые пользуются прям Tornado Cash UI. Если человек серьезно обеспокоен и готов принимать серьезные меры по безопасности, то мы предоставляем консольные инструменты, для того чтобы сделать депозит и полностью контролировать свое окружение.
Роман Сторм: Также юзер имеет возможность взять тот JavaScript, который генерит рандом и, допустим, запустить это через свой localhost или каким-либо другим способом. То есть он не обязан использовать наш домен в браузере, чтобы произвести эту операцию.
Александр Селезнев: Хорошо. У меня такой, может быть, немножко запоздалый нубский вопрос. А можете объяснить выбор технологии? Вот есть же несколько Zero Knowledge подходов (есть SNARK, STARK, там различные bulletproof). Почему вы именно SNARK выбрали?
Роман Семенов: Потому что мы используем proof-систему groth16 – это одна из самых популярных и наиболее production ready систем. Она, в том числе, используется в ZCash. У нее параметры из тех систем, которые сейчас готовы к продакшну, идеальные у нее, маленькие прувы, легко все доказывается. Скажем, у тех же STARK, у них там килобайты могут они занимать, то есть она по всем параметрам нам наиболее подходит. Сейчас в разработке есть различные более перспективные proof-системы (например, PlonK от Aztec, который не требует процедуры Trusted Setup, так называемой), но пока что для них нет хороших инструментов. И, возможно, в будущей версии Tornado Cash уже будут ее использовать, но пока что нет инструментов, не проверена она на практике, нет больших деплойментов, и мы используем что-то более стабильное.
(00:35:05)
Сергей Тихомиров: Тут очень хороший получился переход к следующей теме, которую мы хотели бы затронуть, а именно Trusted Setup. Вы недавно завершили процедуру Trusted Setup. Расскажите, пожалуйста, что это такое, зачем это было нужно и как в результате улучшились гарантии безопасности для Tornado Cash?
Роман Семенов: Proof-система groth16 работает… Это можно легко пояснить на примере, есть программа, которая высчитывает наши хэши и проверяет, что корректно были поданы данные для SNARK на вход, то есть проверяет merkle-доказательства. groth16 система преобразует ее сначала к каким-то матрицам и многочленам, а потом проверяет, что этот длинный многочлен корректен в каком-то наборе точек. То есть, есть какие-то точки, которые он туда должен подставить и получить какое-то правильное значение. И эти точки, они хитрым образом зашифрованы. То есть, в результате Setup генерируются какие-то координаты, а потом они гомоморфно шифруются так, что та сторона, которая генерирует доказательства, она не знает, для каких именно точек она его генерирует. То есть, эта координата, для которой высчитывается многочлен, она как-то хитро зашифрована. И получается, для того чтобы у нас не было возможностей подделывать эти доказательства, нам нужно убедиться, что вот эти исходные точки, то есть Setup как сделан, генерируются случайные числа, точки, в которых многочлены считаются, а потом от них берутся хэши. И нужно убедиться, что эти исходные точки, для которых хэши были сгенерированы, что их выбросили. Иначе, если сторона, которая генерирует доказательства, будет знать, в каких именно местах проверяется корректность, она будет иметь возможность генерировать фэйковые доказательства, которые корректны только в этих точках, а в каких-то других местах могут быть неправильными. Если эти исходные данные были выкинуты и если мы не знаем, для каких именно точек мы генерируем доказательства, нам придется сгенерировать его так, чтобы он было верно для всех точек, иначе у нас наш верифаер его не примет.
Здесь для того, чтобы убедиться, что тот, кто генерировал эти исходные координаты, их выкинул, в ход идет так называемый multi-party computation, то есть какое-то вычисление, которое было сделано на нескольких машинах. И если хотя бы один из участников этого вычисления свои исходные данные выкинул, вот эти исходные точки будет невозможно восстановить и невозможно будет подделывать доказательства.
Сергей Тихомиров: Давай немножко вернемся на шаг назад. Хочу этот вопрос более подробно проговорить про точки и многочлены. Вот если мы абстрагируемся от того, что у нас там наверняка какая-нибудь эллиптическая кривая, какое-нибудь пространство там чего-то. Вернемся в школьный курс алгебры: у нас есть какое-нибудь квадратное уравнение, и у него бывает ноль, один или два корня, допустим, точки, где она пересекает ось, где значение равно нулю. Но вот я сейчас пытаюсь своими словами пересказать, а вы меня поправьте, если я что-то неправильно понял. То есть, задача доказательства того, что у меня есть депозит, короче, какая-то задача в формулировке нашей бизнес-логики, она переводится на язык многочленов. И вот у нас есть какой-то огромный многочлен, и дальше, чтобы доказать то, что я хочу доказать, мне надо предъявить такие входные данные, которые в нужных точках дадут 0, но я не знаю на самом деле, что это за точки. То есть, если бы я знал, что это за точки, тогда мне было бы легко подогнать все, что я хочу, под ответ. А поскольку я не знаю, мне приходится… Ох, сложно как-то это все. Мне приходится генерировать такие данные, которые на самом деле совпадают в каком-то смысле с нужным многочленом везде, а не просто в выбранных точках. Мне кажется, я уже запутался сам. Давайте мы как-то выплывем на более понятную формулировку.
Роман Семенов: Ну, почти. Я попробую в приближении объяснить. Проверяющей стороне нужно убедиться, что доказывающая сторона предоставила нам правильный многочлен. Для начала можно немножко сделать шаг назад и рассмотреть интерактивный протокол. Проверяющая сторона задает очень большое количество вопросов – а чему равен многочлен в этой Х-координате. И доказывающий должен предъявить значение, чему равен У в этой координате, и проявляющий проверяет – правильно, прокатывает или не прокатывает. И если сделать много таких проверок, можно быть с очень большой вероятностью уверенным в том, что действительно доказывающий имеет правильный многочлен, который нам подходит, то есть мы его проверили в большом количестве вот этих точек. А теперь для того, чтоб перейти к неинтерактивному протоколу с помощью всяких хэшей гомоморфного шифрования, мы делаем так, чтобы доказывающему нужно было посчитать У-координату, но он не знает, для какой Х-координаты.
(00:40:00)
То есть, если он имеет этот многочлен, он его как-то считает, но не знает точно, где. И если у него многочлен какой-то неправильный, типа: кое-где он выдает правильное значение, а кое-где неправильное, – есть большая вероятность, что этот запрос с Х-координатой попадет, хотя бы один из этих запросов, попадет на то место, где он неправильный, этот многочлен, и тогда весь proof будет невалидный.
Сергей Тихомиров: Мне кажется, я придумал простую аналогию, которая мне по крайней мере кажется довольно логичной. Оцените, насколько она подходит. Представим, что мне нужно доказать, что я знаю некоторый многочлен, и вы меня просите его посчитать в некоторых точках, но на самом деле вы проверяете значение не в точке X, а в точке Х плюс дельта, где дельту я не знаю, а вы эту дельту знаете. То есть, есть некоторая секретная дельта, и значение подстраивать нужно на самом деле на Х плюс дельта, а ни на Х. И эту дельту секретную, собственно, и нужно уничтожить, потому что если у меня будет это значение, то я буду знать, где мне нужно подгонять под ответ, если я ее не знаю, значит, остается только действительно выполнять все, что от меня требуется – действительно знать тот многочлен, который мы пытаемся угадать.
Роман Семенов: Да, примерно так. И в результате Trusted Setup каждый пользователь просто добавляет какое-то число к этой дельте. И если мы хотя бы одно из этих чисел, которое добавили, не знаем, мы итоговую дельту в итоге тоже не знаем.
Сергей Тихомиров: Давайте мы закончим немножко с аналогией, потому что это ведет нас слишком далеко, мне кажется. Но вопрос такой более высокоуровневый относительно Trusted Setup заключается в следующем. Вот есть же Zcash, и у Zcash тоже был Trusted Setup, причем даже не один. И я помню, что где-то год назад или чуть больше они проводили церемонию Powers of Tau, где была примерно такая же механика, что давайте вместо того, чтобы у нас участвовало 6 человек в самой первой церемонии, давайте мы откроем это для всех желающих, и все желающие смогут внести свой вклад и тем самым гарантировать, что если хотя бы один из них честный, то все у нас честно. И я тогда еще помню, что они писали, что эта процедура, она такая генерализуемая, то есть ее можно было бы использовать, как писали тогда ZCash’цы, не только для Zcash, а вообще в принципе для такого рода церемоний в будущем. Почему вы проводили церемонию свою, нельзя ли было как-то переиспользовать результаты того, что сделали Zcash?
Роман Семенов: Нельзя было, потому что они делали Powers of Tau церемонией для кривой BLS своей, которая сейчас на Zcash (12-351), а мы делали для эфирной кривой BN254. У них разные параметры и нельзя переиспользовать. Но в целом, да, церемония состоит из двух частей. Первая называется Powers of Tau, вторая – Phase 2. И Powers of Tau универсальная для всех SNARK, а Phase 2, она специфичная для каждого циркуита. И соответственно, в Ethereum аналогично сейчас проводятся так называемые Perpetual Powers of Tau, организуемые Барри Вайтхетом и их командой Коби, в которой участвуют. Виталик участвовал и, в общем-то, много участников. Она большая и универсальная для всех SNARK, в том числе и мы ее использовали как основу за Phase 1 и потом на ее основе проводили нашу Phase 2, которая уже специфичная для циркуитов Tornado. Кстати говоря, код для Trusted Setup использовался тот же самый, который использовали Zcash для своей Powers of Tau, но адаптировано туда была добавлена эфирная кривая.
Алексей Перцев: В этой истории церемонии было как раз то, что мы позволили любому желающему, не обладающему техническими какими-то навыками, все равно поучаствовать в этой церемонии, то есть мы построили интерфейс, веб-интерфейс, для того чтобы участвовать в Trusted Setup церемонии, именно в этой второй фазе.
Александр Селезнев: Я как раз, кстати, хотел сейчас закруглить тему Trusted Setup тем, что мне как раз понравилась ультрадружелюбность интерфейса. Я вообще хотел бы сейчас чуть-чуть в сторону сказать: ребят, мне вообще так нравится наш интерфейс. Редко такое встретишь в блокчейн-проектах, когда все сразу понятно, просто даже если ты совсем-совсем не хочешь думать, все за тебя продуманно, это класс. Я как раз хотел сказать, что да, Trusted Setup у вас очень приятно был организован, и, кстати, я даже от «Базового Блока» захотел внести свою лепту, но помню, у меня что-то не получилось, браузер выдал ошибку, а дальше как-то у меня вкладка потерялась. Но это не так важно для истории. Скажите, скорее, то, что действительно важно. Сколько поучаствовало вообще людей?
Роман Сторм: 1124, насколько я помню.
Роман Семенов: 1114.
Роман Сторм: А, 1114, да.
Александр Селезнев: Круто.
Роман Семенов: Из них где-то треть привязала какой-то айдентити, то есть твиттер-аккаунт к своему contribution, и большинство из них сделало публично твит с аттестацией о том, что они сделали такой-то contribution и кто угодно может пойти и проверить, что действительно эти люди публично заявили о том, что они поучаствовали в этой церемонии.
(00:45:01)
Все наши contribution выложены в публичный доступ, можно проверить полностью весь транскрипт нашего Trusted Setup, что он был корректно сделан.
Роман Сторм: И то, что у нас был такой экспириенс, когда вы хотели сделать Trusted Setup, у вас какая-то ошибка была, это говорит о том, что в эту же секунду кто-то уже сделал contribution, и браузеру нужно было опять подтянуть последний contribution, чтобы на основе него сделать свой contribution. Это просто так устроен Trusted Setup: невозможно параллельно делать contribution.
Роман Семенов: Это как раз то, почему у нас в целом User eXperience был удобный, потому что каждый следующий contribution должен делаться на основе предыдущего, и в большинстве других Trusted Setup участники записывались в очередь, для каждого выделялся какой-то тайм-слот, когда он будет делать, генерировать свои параметры. У нас же, поскольку мы знаем, что SNARK относительно маленький и генерируется относительно быстро, мы используем оптимистичный подход, то есть мы надеемся, что когда кто-то генерирует свой contribution, никого параллельно, генерирующего contribution, нет, и если вдруг этот кто-то есть, мы обрабатываем уже этот случай отдельно, то есть его придется просто перегенерировать. Contribution занимает примерно минуту, и очень редкого в одну и ту же минуту два разных участника этот contribution будут делать. Благодаря вот этой системе у нас получилось сделать, что ни в какие очереди не надо записываться, просто приходишь, нажимаешь кнопку – и все работает.
Александр Селезнев: Хорошо. Я еще хотел спросить одну вещь, которую мы пока никак не поднимали. У вас есть такая вещь, как сеть релееров. Скажите, верно я понимаю, что релеер – это человек, которому я делегирую почетную обязанность заплатить газ за то, чтобы вытащить мой эфир, и передать его мне на чистый аккаунт, который заплатить за газ не может. Я верно это понимаю или все-таки что-то не так?
Роман Сторм: Да, я считаю, что вы все верно поняли. Зачем нужны релееры, сейчас объясню. Дело в том, что в Ethereum так называемая есть проблема оплаты газа, то есть чтобы мне совершить любую транзакцию в эфире, я должен иметь, собственно, сам эфир, чтобы оплатить стоимость транзакции. Таким образом, чтобы использовать Tornado Cash, ты сделал депозит и захочешь сделать вывод, тебе нужно каким-то образом сделать этот вывод и заплатить за эту транзакцию. Но если ты откуда-то положишь эфир, чтобы его снять, то уже теряется весь смысл использования Tornado Cash. Поэтому существуют релееры, которые не имеют какого-либо доступа к вашим средствам, так как всё, что они принимают, это уже сгенерировано в ваш ZKProof. Соответственно они даже если бы хотели, они ничего не могут сделать с вашим прувом, они не могут вытянуть ваши средства или еще что-либо, то есть это просто нода, которая принимает ваш ZKProof и сабмитует его ончейн. И таким образом, когда внешний наблюдатель будет смотреть на смарт-контракт, он видит, что вот эти определенные адреса просто делают снятие депозитов. И в этом ZKProof уже вшито конкретно, на какой адрес упадет депозит. Вот и все. Поэтому это безопасный способ. И релеер берет небольшой fee за свою услугу. И также любой, кто нас сейчас слушает, может запустить свою релеер-ноду и участвовать в этой сети.
Александр Селезнев: То есть, релеер – это такой anonimouty-майнер, человек, который получает вознаграждение за то, что провайдит анонимность, как выходная нода Tor.
Роман Сторм: Да.
Александр Селезнев: Сколько сейчас этих релееров?
Роман Сторм: На данный момент, насколько я помню, 4 релеера работает в Tornado Cash, и вроде как с последнего подкаста, который был неделю назад (Into The Ether), вроде как еще какие-то ребята хотят еще поднять свои ноды и подключиться.
Александр Селезнев: А могу ли я поднять ноду релееровскую, никак с вами не взаимодействуя? Просто анонимно от вас стать релеером Tornado Cash?
Роман Сторм: Да, вы это можете сделать. Есть только один небольшой нюанс. Когда вы поднимете ноду, при снятии… Как работает наш клиент: он рандомно из списка выбирает релеера, чтобы не было какого-то цензурирования релееров с нашей стороны, и пользователь, собственно, идет и использует. Также пользователь имеет возможность выбрать конкретного специфичного релеера или вообще вбить свой кастомный URL релеера, если он, скажем, вообще не хочет публиковать, к примеру, что он ранает релеера. А если вы хотите быть в списке самих релееров, вам нужно будет просто сделать, ишью создать GitHub, на репозитории, и мы вас добавим. Мы понимаем, что это на сегодняшний день является, наверное, одним из таких централизованных решений, что мы на UI каким-либо образом контролируем список релееров, но все равно есть у юзера возможность использовать кастомные, и мы эту задачу решим в будущем. У нас сейчас просто не так много финансирования на наш проект и сил, и энергии, чтобы все-все-все решения сделать децентрализованными.
(00:50:06)
Роман Семенов: В основном мы сейчас поддерживаем свой список, для того чтобы просто вручную убеждаться, что мы туда включаем только качественных релееров, у которых хороший ап-тайм, чтобы не оказывалось так, что пользователь отправил какой-то proof, а релеер на него забил и никуда его не засабмитил. Но у пользователя всегда есть возможность еще и кастомного указать.
Александр Селезнев: Но при этом у релеера, как вы уже сказали, нет возможности подставить другой адрес и увести, куда не надо.
Роман Сторм: Абсолютно верно, да.
Александр Селезнев: Хорошо.
Сергей Тихомиров: Ну что, давайте поговорим еще про такой интересный аспект разработки Tornado и вообще смарт-контрактов, как возможность апгрейдов, потому что, как известно, разработчики смарт-контрактов сталкиваются с такой дилеммой: либо нужно full scale децентрализацию, если ты тоже за децентрализацию, казалось бы, то никакого админского ключа у тебя быть не должно. С другой стороны, сложно с первой попытки написать смарт-контракт без багов. А если баги обнаруживаются, то без админского ключа поправить их нельзя. Вот как вы подходите к этому вопросу и как контракты Tornado Cash: обновляемы ли они или они не обновляемы?
Роман Сторм: Да, я расскажу нашу историю деплойментов, как вообще всё происходило. Самую первую версию, которую мы выкатили, это был, по-моему, поправьте, если я не прав, август 2019, там выкатили самую первую версию с депозитами в 0.1 ETH, чтобы начать вообще просто приносить privacy в эфир мейнет и вообще проверять, насколько наша система устойчива. Первую версию мы выкатили с минимальными апгрейдами, но очень вскоре выяснилось, что там была уязвимость И слава Богу, что нам там сообщили, в общем, мы сами себя заэксплуатировали и передеплоили контракт в upgradable смарт-контракт, чтобы дальше продолжать тестировать систему. И только поэтому мы в первой версии имели максимальный депозит 0.1 ETH, что на тот момент являлось, образно говоря, 20 долларов. То есть небольшие суммы и upgradable контракт. Когда мы закончили делать секьюрити аудит, сделанный внешней консалтинговой конторой, мы после этого решились сделать уже контракт, который не upgradable, но он имел пару параметров, которые бы позволяли менять verifier key. Verifier key – это тот самый ключ, который делается при Trusted Setup. Так как у нас не было времени и возможности сделать сразу все правильно, то есть Trusted Setup, мы выложили контракт, в котором можно было менять verifier key, что, в принципе, на самом деле это очень важно, и у нас все еще могла быть возможность, так скажем, забрать чужие деньги. И мы это понимали, поэтому следующим шагом после этого деплоймента было проведение Trusted Setup, чтобы сгенерировать новый verifier key, чтобы его поменять и чтобы народ уже понимал, что ага, вот там теперь verifier key не тот, который мы сгенерировали сами на своих машинах, а это уже публичный refined-ключ. После этого у нас еще одна была функция, которая называлась «оператор», которая, собственно, этот ключ, мультисиг-адрес, который мог менять эти ключи. И мы этот оператор сейчас поставили на нулевой адрес, и всё. На сегодняшний день все контракты Tornado Cash являются неизменимыми и не обновляемыми. И если завтра или послезавтра выяснится какой-либо эксплойт, мы надеемся, что мы узнаем об этом первыми, чтобы мы могли сами эксплуатировать свою же систему и передеплоить новые контракты. Но если это кто-то сделает другой, тут мы ничем уже не можем помочь. Это вечный трейд-офф между… Зачем мы здесь все собрались? Мы здесь все собрались, чтобы строить децентрализованные безопасные системы (trustless и так далее). Ну, мы должны брать определенные риски, точно так же как и наши пользователи должны брать на себя риски, понимая: хотите децентрализованность и безопасность – это ваш выбор.
Роман Семенов: Но здесь еще нужно понимать, что в системах, в которых есть админские ключи, точно так же может найтись какая-то уязвимость, и если о ней первые узнают black hat хакеры, они точно так же могут слить оттуда все деньги, как с неизменяемых систем. То есть этот риск, в принципе, не эксклюзивно для trustless, а этот риск есть во всех приложениях.
Александр Селезнев: У меня по поводу децентрализованных trustless-приложений есть вопрос. Я, конечно, не совсем хорошо представляю, как в подробностях устроен Tornado Cash, но насколько я понял уже, важнейшим участником процесса является frontend.
(00:55:01)
Как мы можем говорить о децентрализованности, когда у нас есть фронт? Но он же где-то хостится, по какому-то домену к нему попадаешь. Что если домен просрочится, какой-то сертификат истечет, не знаю, сервер упадет?
Роман Сторм: Для этого у нас весь унифицированный frontend, который вы можете сделать в Git clone и поднять у себя на машине либо вообще задеплоить на своем домене, вы можете это сделать в любую секунду. Также у нас деплойменты выложены в IPFS. Как мы знаем, если что-то выложено в IPFS и имеется определенный хэш, это тоже уже неизменяемые данные. И да, есть наш домен. И мы в последнем блог-посте как раз-таки упомянули про это, то, что, ребята, пожалуйста, используйте либо IPFS, либо качайте сорс код с GitHub, а Tornado Cash домен может также быть недоступен в каких-либо странах, так как мы не можем контролировать весь Интернет-трафик.
Роман Семенов: И еще я бы добавил, что есть всегда опенсорсный клиент для командной строки, который всегда можно посмотреть. Есть в нашем репозитории примеры, как построить свой UI. Соответственно, любой желающий может разработать альтернативный UI по примерам выложенным и раздеплоить его, как уже сам захочет – опенсорсный, не опенсорсный.
Сергей Тихомиров: Я хотел перейти уже к очередному вопросу, к следующему вопросу – про анонимность. Такой вопрос, мне хотелось бы уточнить про анонимити сет. Все-таки у нас анонимность определяется не в вакууме. Нельзя сказать, что система анонимна или не анонимна сама по себе. Она анонимна относительно какого-то множества людей, которые ею пользуются. Правильно ли я понимаю, во-первых, из описания протокола, что анонимити сет в Tornado Cash состоит из всех пользователей, которые когда-либо пользовались системой, а не из тех пользователей, например, которые еще не вынули свои депозиты? Как здесь определить анонимити сет? И более широкий вопрос, такой, может быть, более экономический и социальный: как увеличить анонимити сет? Потому что если подобного рода тулы будут считаться такой гиковской игрушкой, и пока мы не привлечем большого количества людей, то, получается, технологии нам не очень помогают. Даже если у нас есть крутые Zero Knowledge Proofs, но ими пользуется 5 человек, из которых 3 – это спецслужбы, которые прослушивают эту систему, то эффекта мы не добьемся, к сожалению.
Роман Семенов: По первой части вопроса все верно. Анонимити сет считается из всех пользователей, которые когда-либо использовали. То есть, когда мы видим какое-то снятие, его источником мог быть любой депозит, который когда-либо был сделан. То есть, даже если сейчас, через несколько месяцев, мы видим какой-то withdrawal, он всегда может быть самым первым пользователем, который использовал Tornado, потому что мы не знаем, кто из участников снимал когда депозиты. Естественно, когда мы видим какое-то снятие, большая вероятность, что это один из тех, кто недавно депозит сделал, то есть тут какой-то вероятностный анализ можно применять. Но строго говоря, да, анонимность примерно вот такая. И важное замечание, что анонимити сет отдельный для каждого инстанса, то есть у инстанса в один эфир свой сет, у инстанса в 10 эфиров – свой сет и так далее.
Роман Сторм: Также я бы хотел на вторую часть ответить. Наша как раз-таки задача принести приватность простым пользователям. В данном моменте мы, в принципе, вроде как получаем фидбек, что Tornado Cash использовать не так уж и сложно, абсолютно точно так же, как и обычную Ethereum-транзакцию делать. Но все равно есть некоторые UI challenges, и мы также будем стараться их решать, чтобы приватные транзакции было делать намного проще и легче нашим пользователям.
Третий вопрос был, как увеличить анонимити сет. Только за счет, как в любом software-продукте: чем больше пользователей, тем больше анонимити сет. А как привлечь пользователя – это вопрос к маркетологам каким-нибудь, а не к нам.
Роман Семенов: Но здесь бы я немножко добавил, что часто возникают идеи, что нужны какие-то финансовые поощрения тем, кто хранит деньги в Tornado. Но технически это немножко сложно, потому что мы не знаем, кто из участников хранит деньги в Tornado, кто уже снял, а кто еще нет. Поэтому с технической стороны, мне кажется, самый простой способ увеличить количество пользователей – это просто сделать Tornado удобным, интегрировать его с различными кошельками и сделать так, чтобы было как можно проще и как можно удобнее пользоваться. Пользователя сами придут.
Роман Сторм: И небольшой спойлер, наверное, такой алерт, то, что мы скоро планируем запустить еще один Tornado Cash instance, где, возможно, мы принесем модель небольшого, так скажем, поощрения пользователям, кто будет пользоваться Tornado Cash.
Алексей Перцев: Возвращаясь к вопросу об анонимити сет.
(01:00:01)
Чаще всего это определяется не строгим математическим определением когда-либо сделанных депозитов, а из этого числа еще нужно вычесть тех, кто пошел и публично твит сделал о том, что он сделал в Tornado и сделал списание, тех, кого спалил провайдер Интернет либо Infura. В общем, все те люди, которые не пользуются подсказками о приватности, о том, как нужно правильно пользоваться инструментом. Их всех можно из анонимити сета, к сожалению, убрать. Но это не означает, что всем теперь нужно надевать шляпу, уходить куда-то в подвалы и пользоваться Tornado. Это говорит лишь о том, что у каждого пользователя должна быть степень, до которой он готов жертвовать своим удобством ради приватности. То есть, кому-то достаточно, что нельзя будет просто походить по Etherscan и понять, откуда взялись средства. Кто-то будет хорошо себя чувствовать с этим. Тому, кому нужно скрываться уже от Интернет-провайдера и так далее, ему нужно использовать другие решения. Помимо ончейн-приватности, ему нужно соблюдать еще обычную сетевую приватность.
Александр Селезнев: Хорошо. Вот вы уже сейчас сказали про то, что, как любым инструментом, Tornado Cash тоже надо правильно пользоваться, и вы уже упоминали, что у вас есть прям такой мануал для пользователя, как не допустить ошибку. Вот можете сказать основные пункты?
Роман Семенов: В первую очередь это сетевая приватность, то есть Tornado делает свою работу по обеспечению ончейн-приватности, чтобы на Etherscan было не видно связи. Но при этом есть IP-адрес, который хорошо бы менять время от времени, есть всякие куки, например. То есть, если какое-нибудь приложение видит старый адрес и новый адрес, которые, по идее, не должны быть связаны, но с одними и теми же куками в одном и том же браузере, приложение может знать о том, что эти адреса как-то связаны между собой. Аналогично с RPC-нодой эфира, которой пользуется кошелек. Если он пользуется, скажем, Infura с одним и тем же токеном и запрашивает данные по разным кошелькам (старым и новым), Infura в теории, если бы они хранили логи и их анализировали, то в теории Infura могла бы где-то себе записывать. Скорее всего, они этого, конечно, не делают, но это зависит от модели безопасности для каждого конкретного пользователя.
И второе – это ончейн-часть, то есть если пользователь делает депозит и сразу через две минуты его снимает, внешний наблюдатель может сказать, что с большой вероятностью это один и тот же пользователь. То есть, скажем, этот инстанс Tornado стоял, себе стоял, не знаю, шесть часов и никто в него не приходил, а потом – хоп, в одну минуту сделали депозит и сразу сняли. Большая вероятность, что это один человек был. Особенно, если кто-то сделал, скажем, 18 депозитов, а потом снял 18 депозитов на один и тот же кошелек. То есть нужно применять здравый смысл и пытаться смешаться с толпой.
Сергей Тихомиров: Я бы хотел спросить еще по поводу безопасных практик и сетевой безопасности. Правильно ли я понимаю, я об этом раньше не задумывался, но насколько я представляю, в Ethereum пользователи в основном отправляют транзакции через метамаск, а метамаск, получается, на бэк-энде имеет нод Infura, и все транзакции идут через Infura. Или это не так? Я хотел бы прояснить взаимодействие, если я посылаю транзакцию в Tornado Cash, на какой конкретно нод я ее посылаю из метамаска и насколько реалистично, насколько легко или просто было бы мне использовать Tornado Cash со своей собственной эфирной нодой?
Алексей Перцев: Да, вы верно подметили, что метамаск по умолчанию использует Infura-ноду, и в теории, да, Infura хранит все логи, кто когда-либо делал какие-либо запросы на эту ноду, с каких кошельков и каких IP-адресов. И поэтому вы имеете возможность в метамаске, например, в том же выбрать кастомную prc-ноду, где вы можете указать URL, и вы будете общаться со своей кастомной нодой, и также используя метамаск. Также хочу подметить, что Tornado Cash поддерживается не только в браузере в метамаск, мы также поддерживаем мобильные версии, такие как Trust Wallet, imToken, Status-кошелек и Coinbase Wallet.
Сергей Тихомиров: Хорошо, спасибо. И про сетевую безопасность опять-таки если мы говорим, наверняка возникает вопрос у многих, что на счет Tor. Можно ли пользоваться Tornado Cash через Tor, если у вас onion-адрес, и какие возникают, может быть, сложности с интеграцией Tornado и Tor.
Роман Сторм: Можете открывать Tor-браузер, заходить на Tornado Cash и пользоваться Tornado Cash, и будет работать. Единственное, хочу подметить, что в декстопных версиях у Tor-браузера по умолчанию выключен Web Assembly. Мы даем этот алерт пользователю, что ему нужно зайти в настройки, включить в Web Assembly в браузере, и всё, всё будет работать.
(01:05:04)
Сергей Тихомиров: А для чего вам нужен Web Assembly? Наверное же, Tor его по какой-то причине отключает по умолчанию, считая, что он потенциально небезопасен.
Роман Семенов: Для того чтобы быстро сгенерировать SNARK proof при снятии, то есть депозит можно было бы делать, если бы в Tor был какой-то метамаск или какой-то плагин для эфира установлен, депозит можно делать и без Web Assembly. А вот для того, чтобы снять, и для того, чтобы быстро сгенерировать SNARK proof во много потоков, нужен именно Web Assembly. В теории есть еще snarkjs, который умеет генерировать без Web Assembly, но он это делает в течение двух минут вместо 10 секунд, и мы даже не думали о том, чтоб его интегрировать.
Сергей Тихомиров: И судя по названию, он является JavaScript. А JavaScript, насколько я знаю, в Tor-браузере тоже по умолчанию отключен, да?
Роман Сторм: Нет, неверно. JavaScript по умолчанию, да.
Сергей Тихомиров: Значит, у меня неверная информация.
Роман Семенов: Tor рекомендует его отключать.
Роман Сторм: Рекомендует, но по умолчанию не выключен.
Сергей Тихомиров: Но правильно ли я понял, что если мы говорим о доступе через Tor, то имеется в виду не доступ через выходную ноду на Tornado.Cash, а именно отдельный onion-адрес.
Роман Семенов: Да, там существует Tor, onion-адрес Tornado.
Сергей Тихомиров: Еще небольшой вопрос про Tor. Почитав одну из ишью на вашем Github, там было обсуждение на счет того, что у человека не получалось воспользоваться Tornado через Tor, и причина – это что Tornado запрашивает с некоего стороннего сайта информацию о комиссии, чтобы выставить правильную комиссию в транзакцию. Вот можете рассказать, откуда вы берете оценку комиссии, и если вы запрашиваете ее у какого-то третьего сайта, достаточно ли приватный способ это делать?
Роман Сторм: Да, сейчас объясню. Есть так называемый Gas Price Oracle), которые необходимы, чтобы понимать, какой на сегодняшний день Gas Price (цена) является, чтобы совершить транзакцию, чтобы у пользователя был хороший User eXperience. И как работает релеер? Релеер тоже имеет свои «Gas Price оракулы, чтобы релеер мог понимать: с такой ценой газа я буду с тобой работать, я буду совершать твой вывод. А если юзер выставит меньше Gas Price, чем маркет рейт, тогда релеер просто откажется производить данную транзакцию. Мы на сегодняшний день используем публичные Gas Price оракулы, такие как Ether Gas Station и также еще какие-то провайдеры. Но у нас уже в плане есть решения, которые будут использоваться ончейн. Соответственно, не будет требовать каких-либо запросов на внешние какие-то сервисы, а прямо можно со смарт-контракт будет считать данный Gas Price цены, которая будет предоставлена ChainLink.
Роман Семенов: И еще небольшое добавление. Во-первых, мы сделаем, чтобы не нужно было ходить через выходную ноду на Gas Price Oracle, ноду RPC можно будет указать свою, но для полноты системы нужно еще, чтобы релееры были тоже на onion-доменах, чтобы вообще никуда за пределы Tor не нужно было ходить. И мы думаем, может быть, напишем какой-то маленький туториал, как это сделать, и надеемся, кто-то из релееров, может быть, тоже там раздеплоит на onion-адрес свой релеер, и тогда можно будет полностью без выходных нод, все будет содержаться в Tor.
Сергей Тихомиров: Отлично. Спасибо. Давайте перейдем к следующему вопросу. Следующий вопрос: хотел бы я с вами обсудить ваших потенциальных конкурентов, ну или, скажем так, другие проекты, которые работают в области анонимности на Ethereum. Прежде всего, насколько я понимаю, часто сравнивают Tornado Cash и проект Aztec. Мне кажется, он уже упоминался ранее в разговоре. Можете кратко рассказать, в чем заключается его главная фишка и в чем отличаются ваши подходы, если они отличаются.
Роман Семенов: Я бы тогда, возможно, перед этим сделал небольшой обзор приватности вообще, в том числе других чейнов, и потом перешел к Aztec. Что у нас есть из приватности в целом в крипте? Есть CoinJoin, Wasabi и Samourai Wallets. Они делают join примерно по 200 инпутов где-то раз в два часа. То есть около тысячи с небольшим инпутов в день. Понятно, часть из них всегда повторяется во всех системах. Есть Mimble Wimble, он скрывает, сколько пользователей переводят, но не скрывает, кому они переводят. Он использует какие-то техники, которые частично обфусцируют эти данные, но в теории все равно можно их извлечь, то есть они не полностью скрыты. Есть Monero, который скрывает, у него больше 10 тысяч транзакций в день. Monero скрывает полностью, сколько пользователь переводит, но граф, кто переводит кому, частично запутан, то есть у каждой транзакции есть настоящие входы, настоящие выходы, но еще есть 10 примерно фейковых входов.
(01:10:03)
И поскольку транзакций много и у каждой из транзакций 10 фэйковых входов, помимо настоящих, из-за большого объема, наверное, Monero на сегодняшний день является самой качественной системой, для того чтобы получить хорошую приватность. Затем у нас есть Zcash. У Zcash на данный момент примерно 500 полностью shielded-транзакций. У них бывают открытые транзакции в сети, которых много, и вот shielded, именно приватные транзакции, их примерно 5%, то есть примерно 500 штук в день. Они идеально скрывают граф, то есть у них так же, как и в Tornado, выходом любой транзакции может быть любой из входов, когда-либо сгенерированных за всю историю Zcash. Ну, естественно, скрывают amounts, то есть на сегодняшний день у них самая хорошая именно технология. И на эфире у нас есть Tornado, в котором мы не скрываем эмаунты, то есть у каждого эмаунта у нас отдельный анонимити сет, но скрываем, кто переводит куда, и примерно у нас сет из нескольких тысяч на каждый инстанс.
И есть Aztec. Они в текущей версии скрывают, сколько переводится, но не скрывают, кому переводится, то есть граф, кто переводит кому, он прям полностью открытый. У Aztec очень сильная команда research. Они сделали, например, PlonK, очень крутую пруф-систему, у которой универсальный Trusted Setup один раз делается на все сразу SNARK’и. И они, в принципе, идут к тому, чтобы скрывать граф транзакции тоже. И мы, кстати говоря, тоже идем к тому, чтобы скрывать эмаунты. Мы, наверное, сейчас как следующей темой поговорим, что мы будем делать дальше, что у нас будет privacy pool.
И еще бы я упомянул проект Zero Pool, который тоже предоставляет возможность внутренних транзакций, в своей сети обеспечивает приватность. Но пока что у них ограничено, у них в тестовом режиме 0.1 эфир, кажется, можно ввести в сеть.
Сергей Тихомиров: То есть в итоге, если сравнивать конкретно Tornado и Aztec, ожидается, что они сойдутся в некоторой середине, что Tornado научится прятать эмаунты, а Aztec научится прятать отправителя и получателя, и по итогу функциональность как-то сойдется в такой комбинации.
Роман Семенов: Да, верно. Еще, единственное, я бы упомянул о Matter Labs, которые делают rollup. У них есть планы ввести конфиденциальность, то есть скрывать суммы транзакций, но, насколько я знаю, нет плана скрывать граф.
Александр Селезнев: Хорошо. Давайте сейчас поговорим про радостную тему. Вот вы недавно выиграли грант Gitcoin. Поздравляю, это очень здорово. И у меня сразу встал такой вопрос. Ведь все, кто подаются на гранты Gitcoin, они автоматически подписываются под тем, что их проект делается ради добра, не ради денег, никакой монетизации не подразумевается.
Роман Сторм: Насколько мне известно, нет такого соглашения. Мы как видим, очень много проектов на Gitcoin уже в текущий момент и в предыдущих. И многие из них зафинансированы венчурными капиталистами. Также многие нацелены чисто на коммерческую цель. Мы просто такое небольшое исключение. С точки зрения Tornado на сегодняшний день мы не имеем какой-либо коммерческой заинтересованности, с точки зрения мы не ранаем релееров и мы не имеем никакого профита вообще с Tornado Cash. У нас это больше идет как паблик-сервис на сегодняшний день.
Александр Селезнев: И был вот следующий мой вопрос. Мне показалось, что это весьма неожиданное решение не предусмотреть никакой монетизации. Или у вас предусмотрена какая-то монетизация?
Роман Сторм: Окей. Мы думаем над этим вопросом в следующей версии, как можно сделать так, чтобы это не нарушало каким-либо образом закон и было возможно делать для нас, и делать какую-то систему. Мы думаем над этим. На этим на данный момент, да, почему так все сложилось, да потому что, во-первых, мы как хатанощики бывшие, мы просто сидели хакали. Никто никогда не думал, что Tornado Cash будет таким проектом, все будут как-то о нем писать, пользоваться и так далее. Это был эксперимент. Мы наивно предполагали, кстати, до Tornado Cash, что… Да уже, наверное, многие это сделали, это уже работает и так далее. Но как оказалось, действительно, в мейнете не было нормального продукта, который бы предоставлял приватность ончейн. И так, наверное, сложилось, что мы смогли это сделать. Да, мы не предполагали from day one, что вот нужно делать монетизацию. Мы его запилили, и нам было интересно построить продукт.
Роман Семенов: Во многом еще юридической стороной обусловлено, то есть мы не хотим использовать никакие способы, которые бы нарушали законодательство в Штатах или где-либо еще.
(01:15:05)
И, соответственно, какие-то компании, которые в других странах сидят, им, возможно, о’кей делать некоторые там ICO, exit scam и ещё что-то. Мы хотим сделать так, чтобы всё было 100% законно, и, соответственно, многие из вариантов нам просто не подходят с юридической точки зрения.
Александр Селезнев: А вот, кстати, очень интересный вопрос. Почему, что там может быть незаконно, как именно, если это не секрет?
Роман Сторм: Мы сами не адвокаты, просто нам как бы советуют: вам будет, например, на данный момент легче, если у вас нет коммерческой заинтересованности с точки зрения законодательства. И таким образом, какой-то ряд законов к нам тогда не относится, потому что у нас нет коммерческой заинтересованности. В общем, мы сами пока что не совсем хорошо понимаем, что можно делать, что нельзя делать, но вот как-то стараемся относиться к таким решениями очень предельно осторожно и аккуратно.
Роман Семенов: Ну и тут стоит заметить, что сфера новая, закон четко еще не прописан, то есть многие сами юристы тоже не имеют четкого понимания, потому что не было прям четких инструкций от регуляторов и тех, кто эти законы делает. Соответственно, поскольку четкого понимания нет, мы стараемся быть на безопасной стороне и делать то, что мы точно знаем, что о’кей.
Роман Сторм: Есть определенный гайдлайн от всемирно известной организации FinCen, которые выпустили в прошлом году, в мае 2019 года, некоторый ряд гайдлайнов, что можно, что нельзя, кто подходит под регуляции, кто нельзя. Суть из этого гайдлайна: у нас, в принципе, всё хорошо. И что я имею в виду, что там четко написано, что anonymizing software provider is not subject to money transmission, что означает, что тот, кто занимается предоставлением софта, который анонимизирует транзакции, не должен иметь money transmitter licensing – это лицензия, которую, в общем, все центральные биржи должны иметь, и они имеют, чтобы управлять юзерскими средставми.
Александр Селезнев: Ох, в общем, вам предстоит нелегкий путь по минному полю американской правовой системы, я чувствую. Но будем надеяться, что у вас всё получится. А вот перед тем, как мы перейдем к завершающей части нашего подкаста, к вопросу о планах, я вот хочу задать такой вопрос. А как вот так получилось (ни для кого, я думаю, не секрет), что вас очень поддерживает Ethereum-сообщество и что вот лично Виталик очень радуется от вашего проекта. Как получилось, что это ещё не вылилось в грант, например, от Ethereum Foundation.
Роман Сторм: Очень хороший вопрос, и мы сами не знаем, почему до сих пор у нас нет гранта от Ethereum Foundation. Если коротко, да, нам самим интересно, хотелось бы понять, почему, но тем не менее, многие, наверное, всё равно, кстати, нас спрашивают: а каким образом вы получаете поддержку публично от лидеров мнений индустрии, от таких, как Виталик и разных людей? Ответ прост: ребята, делайте просто продукт, который полезен рынку, и думайте о качественном UI.
Александр Селезнев: Расскажите, какие у вас планы на ближайшее будущее? Что вы планируете делать в ближайшее время, чтобы увеличить количество людей, которые пользуются Tornado Cash, и безопасность?
Роман Сторм: Как мы уже выше упомянули, у текущей версии Tornado Cash есть ряд ограничений, и мы эти ограничения, конечно же, хотим расширить. Такие как: избавление от фиксированных эмаунтов в пулах, чтобы это можно было любой, чтобы сделать один privacy pool, который такой же, похожий, как у ZCash, с любым эмаунтом пересылать. И вторую, наверное, важную фичу, которую мы хотим сделать. На данный момент Tornado Cash работает на то, что ты завел и вывел из пула, и ты внутри пула не можешь передать ownership (владение) своих средств какому-либо другому адресу. Мы также хотим разработать эту функциональность, где ты можешь завести в пул и внутри пула отсылать кому-либо другому средства. Если ещё что-то есть добавить – пожалуйста.
Роман Семенов: Ну, в принципе, я бы немножко добавил про стадию Proof of concept. У нас есть command line вариант, который всё это уже делает. Но для того чтобы его превратить в продукт, еще предстоит достаточно много работы, и первым делом найти на всё дело финансирование.
Роман Сторм: Да, у нас сейчас пока что есть проблемы в этой части. Всё ещё у нас нет финансирования на следующую версию, и мы думаем, как эту проблему решить, и рассматриваем разные варианты. Если у кого-то есть какие-либо интересные идеи или предложения, пожалуйста, приходите в наш Telegram или можете найти всех наших тим-мемберов тоже Telegram и начинайте с нами общение.
(01:20:11)
Мы довольно открыты к людям и всегда готовы выслушать ваши предложения.
Роман Семенов: Ну и в целом я бы ещё глобально упомянул по приватности, что есть всякие чейны (типа ZCash и Monero), основной отличительной функцией которых является, что у них приватность есть, но в Ethereum приватность можно реализовать на точно таком же уровне, но это будет как одна из фич Ethereum вдобавок ко всей экосистеме, которая уже есть. То есть, в принципе, на Ethereum возможно реализовать всё то же самое, что есть в отдельных именно privacy coins, но при этом так, чтобы оно было интегрировано во всю остальную экосистему Ethereum и приносило гораздо больше. Собственно, это наша основная цель на будущее.
Алексей Перцев: Есть ещё одна большая задача, которую не совсем понятно, как решать. Это вопрос интеграции с другими какими-либо решениями, продуктами, воллетами. И прежде чем даже приступить к какой-то интеграции, нам нужно сперва вообще понять самим, как будет работать следующая версия, и пройти через этот процесс коллаборации с другими известными продуктами, кошельками. Это также в нашем roadmap.
Роман Сторм: Да, просто быстренько поясню. Дело в том, что сделать продукт, который можно будет легко интегрировать в другие DeFi-solutions, нетривиально, потому что большинство DeFi-продуктов не были построены с privacy в своем понимании, чтобы какой-то privacy там был. Они, как правило, все не приватные. И это будет очень сложной задачей для нас, чтобы дать возможность людям подключать приватность к их уже существующим протоколам на Ethereum.
Александр Селезнев: Я думаю, что мы можем завершаться. И если вам есть ещё, что прорекламировать или к чему призвать наших пользователей, то сейчас самое время.
Роман Сторм: Gitcoin Grant всё ещё открыт. Если кому нравится, что мы делаем, можете контрибьютить на Gitcoin Grant. И также повторюсь, если у кого-то есть какие-то очень хорошие идеи или если вы хорошо разбираетесь в Zero Knowledge, технологиях или так далее, вы хотели бы поконтрибьютить в Tornado Cash протокол или поделиться своими наработками, идеями – пожалуйста, мы открыты всегда и готовы принять новых участников.
Роман Семенов: Ну и в том числе открыты к идеям по финансированию.
Роман Сторм: Да.
Александр Селезнев: Да, все ссылки на аккаунты ребят будут в шоунотах к выпуску. Алексей, ты что-то хотел сказать?
Алексей Перцев: Я хотел конкретно для пользователей еще раз упомянуть, что Tornado решает только ончейн privacy. Пользователям всё ещё нужно уметь правильно пользоваться инструментом, чтобы достичь желаемого. Для этого у нас есть гайдлайны, наши какие-то статьи, пояснения и так далее.
Александр Селезнев: Здорово! Большое спасибо. Спасибо, ребят, очень интересный выпуск. Мне очень понравилось.
Я хочу сказать спасибо нашим слушателям за то, что нас слушали. Хочу сказать спасибо патронам, которые поддерживают нас на patreon.com/basicbloсkradio. Хотел сказать большое спасибо нашим спонсорам Solana – самый быстрый блокчейн со скоростью 60 тысяч транзакций в секунду. Хотел сказать спасибо HodlHodl – это быстрый и безопасный способ купить и продать биткоины без KYC, а также компании Zerion. Zerion помогает DeFi проникать в массы.
Сергей Тихомиров: Ну и, конечно, не забывайте заходить на наш сайт basicbloсkradio.com, следить за нашими аккаунтами в YouTube, Twitter и Telegram, и в нашем чате в Telegram ББ-чат обсуждать этот выпуск и другие интересные, связанные с блокчейном темы.
Александр Селезнев: Большое спасибо всем. Благодарю вас за то, что пришли к нам сегодня в гости. Пока!
(01:24:04)
Конец записи