ББ-207: Кирилл Пименов (Kampela) о хардверном сайнере

Дисклеймер: расшифровка сделана ИИ, возможны неточности.

Сергей Тихомиров: Всем привет! С вами снова подкаст «Базовый блок», подкаст про блокчейн. У микрофона Сергея Тихомиров, и сегодня у нас в гостях Кирилл Пименов. Привет!

Кирилл Пименов: Привет!

Сергей Тихомиров: Кирилл – CEO компании Kalapaja, которая разрабатывает в числе прочего хардверные кошельки Kampela, а также платежную систему Kalatori. Мы сегодня поговорим про эти проекты, главным образом, я думаю, про кошелек, хотя и про систему тоже.

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

А также мы говорим спасибо нашим спонсорам. Наши спонсоры – это Fluence – облачная платформа на базе децентрализованной инфраструктуры, которая предоставляет более дешевую и отказоустойчивую альтернативу традиционным облачным решениям, таким как AWS, Digital Ocean или Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру. При этом значительно снижаете расходы и не зависите от одного провайдера. Спасибо Fluence!

Также нас поддерживает Zerion. Zerion API – это мощный инструмент для Web3-разработчиков. С его помощью можно в реальном времени получать данные о кошельках, токенах, DeFi-позициях и NFT на более чем 24 блокчейнах, включая Ethereum и Solana. API предоставляет детальные человекочитаемые транзакции, мультичейн, uptime 99.9%, масштабируемость свыше 1000 запросов в секунду. API Zerion используют такие компании, как Uniswap, OpenSea, WalletConnect, Rainbow Wallet и другие. Спасибо Zerion!

Нас также поддерживает 1inch. На долю 1inch приходится около 60% рынка DeFi-агрегации и более 1 миллиарда долларов оборотов в сутки. 1inch уже проводит кроссчейн-свопы между Ethereum, Base, zkSync и другими EVM-сетями. Кроссчейн Solana в финальной стадии. Профи оценят Pathfinder – топовый алгоритм 1inch, который помогает эффективно трейдить. Подключайтесь через API на 1inch.dev или прямо в интерфейсе 1inch.io.

И last but not least, нас поддерживает GOSH, соразработчик блокчейна Acki Nacki, основанного на новом протоколе, достигающем консенсуса за две итерации с самым быстрым и теоретически возможным. GOSH готовится к запуску mainnet в ближайшие месяцы. В коммьюнити уже более 4 миллионов участников. Заключены контракты, партнерство с Oracle и Ampere Computing. Основные направления развития – мобильный гейминг, биодиверсити-активы, мемкоины и DePIN. Большое спасибо GOSH, спасибо всем спонсорам и нашим патронам.

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

Ну что, Кирилл, давай, наверное, начнем. Я посмотрел в архив нашего подкаста и увидел, что ты у нас был в гостях последний раз аж в 2020 году, когда у нас были дебаты о гавернансе децентрализованных проектов с Глебом Науменко. Много воды утекло с тех пор. Может быть, вкратце расскажи, что поменялось в твоей профессиональной жизни с тех пор, а потом мы углубимся в детали.

Кирилл Пименов: Ну, самое важное, что произошло – я в конце 22-го, начале 23-го года ушел из Parity на вольные хлеба и делаю некоторое количество своих проектов, а также пытаюсь по мере сил помогать проектам, которым нужен кто-то, кто много и с 17-го года занимается именно прикладной безопасностью и opsec’ом блокчейна. И сейчас как раз это выливается в то, что самое-самое время запускать штуку новую, которую я придумал, и платежку.

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

Вот какой-то такой фундаментальный тейк.

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

Кирилл Пименов: Ну, я не знаю, как это самым настораживающим или настораживающим, но вот у меня был опыт, от которого я сгорел совсем, когда я был на EthCC в Каннах в этом году. И да, поскольку у меня проект, они предполагают какое-то венчурное финансирование, я разговариваю с какими-то венчурами, я подхожу к одному из них и говорю, что ну вот мы вот придумали, как делать такую штуку, она вот, да, ровно что у вас там, это было заявлено, стейблкоин, payments для e-commerce, давай разговаривать. Он такой: «Нет, нам нужны только абсолютно эти самые regulatory compliant». Я такой: «Ну я придумал, как нам не делать KYC и быть regulatory compliant». «Нет», и короче, как бы через 4-5 итераций выяснилось, что его понимание regulatory compliant, что они сейчас напишут эти законы, так что как бы все, в кого они их не проинтегрировали, окажутся за бортом.

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

И это печально, это печально, что все ведутся, что многие проекты выпускают эти несчастные Visa, там Mastercard, карточки с обеспечением криптой, казалось бы, весь смысл в том, чтобы этого не делать, мы изобрели альтернативу жизни. 15 лет прошло с выпуска этой самой статьи Сатоши, и вот мы радостно бросаемся в объятие Mastercard, потому что мы не смогли сделать удобнее, ну в некотором смысле, как бы я не могу Молоха обвинять в том, что он Молох, я не могу обвинять эти государственные супер-структуры в том, что они пытаются сохранить преумножить свою власть, типа эти самые банки с Wall Street в том, что они пытаются сохранить преумножить свои деньги, это все же ожиданно, а вот то, что шифропанки могли бы несколько больше стоять на своих убеждениях и видеть такие разводки, это было бы конечно неплохо.

Сергей Тихомиров: Вот то, что ты говоришь очень перекликается буквально в прошлом выпуске 206, где у нас был Влад Деген в гостях, он рассказывал, насколько большую долю расходов обычного стартапа составляет compliance и legal, и что вообще-то с точки зрения технологии, но видимо как раз да, вот эту дихотомию тоже можно подсветить, что если человек хочет просто сделать ну какой-то стартап в крипте, по технологии более-менее понятно, все готовые компоненты уже есть, нужно их просто в нужном порядке совместить, а вопрос в том, как ты будешь compliance и сколько ты миллионов или десятков миллионов долларов заплатишь юристам, чтобы они сделали свои юридические все штуки, учитывая, что большие игроки с другой стороны работают со своими юристами, чтобы тебе не разрешить с ними конкурировать.

Кирилл Пименов: И это абсолютно понятная проблема, это в целом результат того, что мы как-то недостаточно, что ли, идеалистичные все шифропанки, а мне кажется, что этот шифропанкский идеализм, он должен в реальный мир, кажется, быстрее вырываться был, и вот сейчас вот как бы у нас проблема в том, что вот такой тоже идешь, поэтому по Каннам, по Бангкоку, по каким-то этим криптоконференциям, все красивое, большое, много проектов, миллионное финансирование, вот, люди объявляют, например, я абсолютно, я очень не люблю говорить плохо про конкретные проекты, поэтому это будет такое очень как бы аморфные все указания, что на фонды, что на проекты, вот, типа у нас первый там настоящий он-чейн-банк, такой, о классно, значит, ну вот в твоем он-чейн-банке, вот у меня автомастерская, я хочу купить себе второй подъемник и расшириться, как мне получить в твоем банке кредит, как мне он такой, ну можно оставить NFT как залог, ну понятно, вот как бы вот страшно вы далеки от народа, и это какая-то странная ментальная проблема, но она приводит к тому, что так, а надо, значит, нам где-то брать реальных пользователей, где мы берем реальных пользователей, там, где уже сейчас есть банки, мы идем как бы в ту же нишу, где банки уже есть, и пытаемся сделать то же самое, просто чуть-чуть там подешевле, и получается, ну как бы многие банки там как бы внутри вместо своих этих ужасных у чертовых систем на COBOL радостно пилит Hyperledger, там, Fabric какой-нибудь до сих пор, это как бы несколько, я в открытой коррекции не встречал с 19 упоминаний, но как бы внутренние системы, и все становится быстрее, надежнее, они там радуются этому всему, это ну не совсем цифровой кэш без участия государства, который мы, наверное, хотели бы для того, чтобы остановить чертову балканизацию планеты.

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

Кирилл Пименов: Да, ну как бы, во-первых, не просто плоскую рыбину, а плоскую рыбину с электронными чернилами на одной стороне, что еще более похоже на тот кошелек, который у меня в итоге получается. Да, я, ну, собственно, моя предыстория, я был ответственным за всякого рода безопасность и пользовательские проекты в области безопасности в Parity, и один из как бы важных проектов, и в какой-то момент было смешно, что я как будто бы CISO, но у меня единственный client-facing продукт, который вообще у компании есть, и это Parity Signer. У нас была, ну, и это продолжает работать идея, что если взять свой старый телефон, на котором уже, тем не менее, есть там какой-то secure enclave и в целом шифрование диска, то из него получится довольно пристойный оффлайновый подписыватель транзакций. 

Оффлайновый в том смысле, что ты его вообще навсегда загоняешь в самолетный режим, и дальше все взаимодействие с внешним миром – это камера и экран смартфона. Экран смартфона прекрасный, он гораздо больше, чем, особенно на тот момент, как бы экраны, которые могли предложить Ledger и Trezor, на нем видно многие транзакции, ну потому что, опять же, транзакция реального мира – это не отправить 10 долларов там кому-то один раз, это, например, кто-то сидит, и в компании на 100 человек отправляют payroll, и вот у него вот 100 этих записей в одну транзакцию желательно, и он их все отправляет. Чем больше экран, тем больше информация влезает, тем больше вероятности, что какую-то ошибку мы действительно там заметно найдем. 

Вот, и Parity Signer жил-жил, сейчас он называется Polkadot Vault и получил как бы прекрасную новую жизнь в руках классной продуктовой команды Nova Wallet, и он продолжает быть опенсорсным, и кто-то потихонечку начинает пилить похожие решения, но в целом он в своем классе единственный, уникальный. И там было придумано довольно много забавных штук, потому что как только начинаешь делать вот эти вот офлайновые кошельки, ты неизбежно сталкиваешься с фундаментальной проблемой аппаратных кошельков, можно прямо секцию так назвать, которая состоит в том, что у блокчейнов, ну если мы не берем какой-то совсем простой Bitcoin или что-то такое, у них есть какая-то семантика того, что ты с ними делаешь, и она зависит от того, в каком состоянии блокчейн сейчас вообще-то находится. И самое простое, я пытаюсь перевести денег, у меня таких денег нет, а транзакция зафейлится, но офлайновый кошелек об этом не знает, но более сложные вещи, это, например, вызов смарт-контрактов на EVM-сетях, где вообще никак не понятно, что ты вызываешь, если у тебя там нет информации об ABI или по возможности как-то просимулировать этот смарт-контракт в виртуализированном environment и так далее, то есть ты даже не знаешь, как называется тот метод, который ты вызываешь.

Сергей Тихомиров: Follow-up вопрос, действительно, это одна из тем, которую я хотел позже осветить, давай подробнее остановимся, насколько я понимаю, в большой части случаев все равно хардверный кошелек предполагает использование его с каким-то companion application, который находится онлайн. В чем проблема, если у меня есть онлайновый кошелек, он подтянет информацию из блокчейна, мне его покажет, а хардверный кошелек будет только подписывать?

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

Вопрос, и там много интересных философских и тоже шифропанковских вопросов, типа вот, может быть, мы можем увеличить аппаратный кошелек до большой доверенной аппаратной платформы, которая вот твой весь ноутбук занимает, и это то, что Microsoft, например, делает. Microsoft же делает свои прекрасные trusted environment, требует от производителей ноутбуков для Windows 11, чтобы они там были, там есть какой-то Windows Hello, обязательно сканер отпечатка пальцев, это движение в ту сторону. К сожалению, это означает, что компьютер перестает быть твоим, начинает быть компьютером Microsoft, но типа зато не у мошенников, что лучше непонятно.

Вот, поэтому ты не можешь полностью довериться тому, что видит твой онлайн кошелек, его могут подломить там десятью разными способами. Мы все помним недавнюю атаку, например, на Multisig Gnosis, где не то что у тебя на компьютере, а в глобальном CDN через supply chain атаку и отравление, по-моему, node modules, на компьютере одного из разработчиков был установлен backdoor, который активировался у конкретного клиента при конкретной транзакции, и что-то там такое подменял в том, какую транзакцию действительно Gnosis подписывает, а на экране ты видел все нормально. Вот, это вот та модель атаки, которую мы им вообще имеем в голове, когда мы говорим про аппаратные кошельки. 

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

Кирилл Пименов: Да, и это не чисто крипто штука – это когда ты подписываешь договор с банком, тебя всегда просят читать мелкий шрифт, потому что там тоже есть какие-то эти backdoor’ы, которые пользуются тем, что у тебя в голове нету всего кодекса знаний о том, как эту индустрию устроили, они пытаются тебя как-то где-то прожать. Это абсолютно понятная история, вот такая вот, заобывательская, просто, да, она гораздо более наглядна и бинарна в случае кошелька, который ничего не знает, что там за чейн и куда ты переводишь, и самое-самое простое вот для техно и как бы объяснение, которое я обычно использую, твой кошелек не может про все токены знать, сколько у них знаков после запятой, мы вот, мы правильно делаем fintech на блокчейне, мы делаем его в интах и числах с фиксированной запятой, мы не используем float, мы молодцы, мы лучше нескольких больших немецких банков, про которые как бы я слышал разные истории, про то, какой у них внутри соус работает, вот, но ты не можешь это знать про все токены и выходов у тебя два, ты можешь либо зашивать знания о каких-то дефолтных токенах самых частых в свою прошивку, и тогда у тебя получается, что твоя прошивка обновляется каждый божий день, что, ну, во-первых, само по себе проблема, потому что что будет, если я не обновил, а что будет, если кто-то поставил backdoor в обновление, а я привык, что я каждый раз, когда пользуюсь кошельком, я сначала обновляю прошивку, целый спектр вопросов, а второй способ – это каким-то образом убедить блокчейн, потом проверять то, что ты показывал человеку на экране, не то, что ты показывал как транзакцию, а то, какие знания ты использовал для того, чтобы это человеку презентовать, то есть иметь какой-то словарь, иметь какие-то метаданные про твою транзакцию, которую блокчейн потом сможет проверить, потому что в блокчейн мы верим, если кто-то сможет заставить блокчейн принять неправильную транзакцию или, там, плохо что-то посчитать, то мы все обречены, это все не имеет смысла, никакие деньги никуда не подходят.

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

Кирилл Пименов: Вот, давай вот этого разберем побольше, мы, естественно, попадаем в мир, в котором живут люди, которые сделали прекрасные GitHub-репозитории, что происходит, когда я ввожу Google.com в браузер и нажимаю Enter, и там до электросхемы они вниз разбирают, как работают свечи на аппаратном уровне, прекрасная абсолютно нердовская тема.

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

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

Сергей Тихомиров: Сейчас, подожди, этот небезопасный, этот режим для профи-юзеров предполагает, что именно? Показывание, собственно, хэша, показывание вот этих байтов.

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

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

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

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

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

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

Сергей Тихомиров: Давай, наверное, знаешь, как поставим вопрос, вот учитывая эту фундаментальную проблему или задачу, как к ней подходят разные существующие производители хардверных кошельков, и как здесь Kampela смотрится в этом пейзаже, почему нужен еще один аппарат, еще один сайнер, да, и как вы эту проблему решаете по-другому, если вы решаете по-другому?

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

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

Кроме этого, действительно прошивки, особенно прошивки DeFi богатых сетей, они очень пухнут, они пухнут, потому что туда надо постоянно зашивать большое количество знаний про все мемкоины, которые вышли за последнюю неделю. И это никому как бы невозможно впихнуть в приложуху, какие там у них лимиты, я не помню, там 512 килобайт, что ли, на базовые модели, что-то такое.

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

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

Сергей Тихомиров: То есть в этой модели мы получается все равно доверяем телефону, что он правильно нам покажет на экране, что мы подписываем, а сайнер просто тупо подписывает все, что ему телефон передаст.

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

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

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

Но мы решили, что нам этого мало, и мы придумали сначала для Polkadot вот эту концепцию метаданных, метаинформации, которую блокчейн должен о себе самому знать. У блокчейна есть какое-то представление о том, как парсить собственные транзакции. Ему на самом деле не надо знать всю эту метадату, ему не надо ей оперировать, то, что ему надо знать, ему надо знать Merkle hashroot от дерева Merkle, который этот весь словарь описывает.

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

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

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

Сергей Тихомиров: Окей, сейчас, я просто тогда…

Кирилл Пименов: Здесь прямо как бы number of decimals как вызов, по-моему, если я не путаю.

Сергей Тихомиров: Окей, я, наверное, тогда в твоем объяснении не совсем понял, что значит блокчейн должен знать, а Ethereum блокчейн не знает, что он тоже знает, сколько у него знаков после запятой в каждом токене.

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

Сергей Тихомиров: А чем это отличается просто от валидации корректности транзакции в обычном сценарии?

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

Сергей Тихомиров: Сейчас, подожди, вот давай, я не знаю, может быть, тут какая-то есть Polkadot-специфика, которую я не понимаю, но я вот буду сейчас в терминах Ethereum как-то пытаться это интерпретировать, а ты опять-таки скажи, если что-то здесь фундаментально не так. То есть вот есть Ethereum, я могу на него задеплоить ERC-20 контракт, и там у меня будет какой-то number of decimals, какая-то возможная внутренняя логика, которая внутри этого стандарта зашита. И дальше я хочу отправить тебе какое-то количество токенов, подписав их сайнером. Сайнер не знает, сколько у меня знаков после запятой, поэтому он мне не может показать в человекочитаемом виде, что я собираюсь подписать.

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

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

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

Сергей Тихомиров: Я сейчас, знаешь, понял, чего я не понимаю, что если мы предполагаем в нашем интернете безопасности, что онлайновый кошелек может быть скомпрометирован, так он просто подменит адрес, куда я отправляю свои монеты. Мне сложно понять с точки зрения блокчейна, чем отличается транзакция. Я тебе послал 10 своих кастомных токенов или USDT или USDC, или я их послал к какому-то злоумышленнику, который захватил мой компьютер и подменил твой адрес своим адресом. С точки зрения блокчейна, это просто два каких-то адреса. Как блокчейн может сказать что-нибудь в этом случае?

Кирилл Пименов: Что мы не можем сделать, тут у нас есть только небольшие UX улучшения. UX улучшения состоят в том, что наш пользователь типа знает пару адресов. В отличие от всех остальных вещей, типа decimals в стандарте ERC-20, то, что он переводит что-то куда-то на какой-то адрес, этот адрес приблизительно похож на ужасный, вот этот самый длинный IBAN номер, по которому он обычно переводит банки, он в общем понимает.

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

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

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

В этом плане адреса можно показывать, их надо как дальше дорабатывать, как они юзер-френдли, это большая экосистемная задача. Но это, если ты в целом UX всего процесса не переусложнил, и человек не делает, о, опять эти самые байт-коды на Ledger прокликивать по двадцати экранах, даже на доске я, да, мы все равно Multisig 3 из 5 кто-нибудь-то проверили. На раз обычно так садятся, каждый думает, что остальные проверили.

Адрес это меньшая из проблем, потому что адрес хотя бы есть некоторое ожидание взаимное, что мы на него посмотрим, и мы как бы понимаем, что он там есть, что он участвует в разговоре, и если его подменить, будет плохо. А вот показывать человеку, что типа, вы знаете, по-моему, у USDC восемь знаков после запятой, ответ что? То есть невозможно заставить человека вот это знать про все токены, с которыми он взаимодействует. Особенно невозможно заставить человека знать про это, про все токены, с которыми он взаимодействует, потому что он на DEX-е что-нибудь одно меняет, на что-нибудь другое.

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

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

Можно ничего не делать, вот это как бы Keycard так делает, и в целом, то есть можно просто поверить. Можно иметь хардкод, это вот то, что делает Ledger, отчасти Trezor, у Trezor поменьше инженерная команда, поэтому видно, что они больше всего не поддерживают и предлагают тебе самому вот это вот все как бы с байт-кодами оперировать, вот. Но в целом, как бы вот такое индустриальное стандартное решение.

Но можно в некоторых блокчейнах специально написав дополнительную обвязку и как бы ужа с ежом подружив, научить твою подпись над транзакцией, нести какую-то вот эту дополнительную информацию, кроме самой транзакции. И эта дополнительная информация, если разговаривать вот как бы инженерно, это все дополнительные куски информации, которые мне были нужны, чтобы байт-код превратить в визуал на экране. То есть там может быть, что адрес вот такой-то, это токен с тикером USDC, что у этого токена столько-то знаков после запятой, что это… вот. Сколько-то таких вещей, и тогда вместо байт-кода ты видишь, я перевожу 10 USDC со своего адреса на адрес вот этот. Мы поговорили, что адрес ты сравниваешь, а мы пытаемся тебе помочь и рисуем их графикой, а не только буквами цифрами.

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

А потом я чуть-чуть коснусь того, что мы думаем, как это можно сделать на Ethereum, но тут момент такой, что почему Kampela до сих пор не продается из каждого утюга, потому что мы не на 100% уверены, что наши решения корректны. Мы плотно работаем с Ethereum Foundation, мы сейчас скорее всего получим грант на то, чтобы эту технологию полностью как бы завалидировать и опубликовать, и я надеюсь, другие кошельки тоже будут вместе с нами пользоваться именно нашим решением.

Но я по суеверным в первую очередь причинам не хотел бы публиковать прямо сейчас наши идеи до того, как мы убедимся, что они всегда в 100% случаев работают, поэтому я буду чуть-чуть обходить стороной какие-то конкретные там те самые способы устроить именно это на EVM сетях.

Но начнем с Polkadot, там есть RFC, который уже имплементирован, Polkadot, все субстратные runtime ему обучены, и это позволило сделать то, что на Ledger сейчас называется Ledger Unified App, то есть кроме нашего хардверного кошелька, Ledger Unified App для Polkadot и субстратных сетей, оно тоже знает про этот принцип подписания дополнительной метаданных, и поэтому можно сделать одно Ledger Unified App для всех апов на субстрате, и оно при этом будет тебе магическим образом на каждом блокчейне его специфические транзакции правильно парсить.

И это все опирается на довольно странную особенность Polkadot, которая состоит в том, что на большом количестве Polkadot-чейнов нет вообще смарт-контрактов, и они не очень нужны, потому что если мы посмотрим то, как у нас даже на EVM, какие смарт-контракты используются, какие нет, у нас будет гигантское бимодальное распределение, здесь ERC токены, ERC-20, NFT-шки там и чего-то еще, и все остальное мелкое.

И вот Polkadot, ну вообще субстрат как фреймворк предполагает, что вот эти типовые вещи, ты будешь прямо хардкодить в runtime, ты будешь иметь к ним специальные системные вызовы, у тебя не будет байт-коды, которые надо будет на каждый такой вызов интерпретировать, а мы прямо возьмем и в виде WebAssembly Blob выложим это, и все наши узлы сети будут знать, что транзакция номер 127 это asset-трансфер, и она переводит asset с таким-то ID-шником, с такого места на такое.

Сергей Тихомиров: Вопрос опять-таки в эфирной терминологии, правильно ли я понимаю, что это похоже на precompile, только возможно на более высоком уровне абстракции, т.е. мы не делаем то, что каждый нод знает, что такой-то байт-код это ZKVerify и что-нибудь такое, а мы говорим, что такое-то transaction ID это token-transfer?

Кирилл Пименов: Да, и это похоже на precompile с некоторой как бы заметной звездочкой, которая состоит в том, что благодаря тому, что вот у нас есть концепция runtime, runtime-извиняюсь, governance, вот это вот все, что Polkadot сделал и другие субстратные цепи подхватили, это в целом такая довольно живая, как в этот самый бурлящая среда, в которую довольно легко с ведома всех стейкхолдеров добавлять фичи, т.е. она занимает место где-то посреди между Ethereum precompile и Ethereum смарт-контрактами, потому что у нее есть governance, и она без остановки перезапуска клиента на всех клиентах начинает быть новой после часа X, и вот знание про все эти precompile-ы составляет метаданные для конкретной цепочки.

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

Сергей Тихомиров: То есть правильно ли было бы, ну, возможно, как-то тоже переформулировать, и удостовериться, что я бы, крайней мере, правильно понял, что дерево Merkle, которое собирает в себе информацию о том, ну, грубо говоря, у какого токена сколько знаков после запятой и похожего рода вещи, оно собирается в один root, и этот root становится частью логики, собственно, нода, который оперирует сам блокчейн, и этот нод знает, что, окей, если мы сейчас находимся там в интервале block height с миллиона до двух миллионов, у нас такая-то логика, плюс она валидна при условии вот такой-то метаданных, а на блоке два миллиона у нас следующий governance какое-нибудь голосование, у нас будет обновление этих метаданных, и там, возможно, что-то меняется или добавится или что-то такое. Но что пока из этой картины мне не совсем понятно, это как здесь хардверный сайнер в эту картину вписывается?

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

Сергей Тихомиров: В смысле Merkle root всех метаданных.

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

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

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

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

Ну что же сделать? Блокчейн – киберсоциальная система. Кибер менять быстро, социальная – менять долго. Ну вот, да. И нашли ли мы оптимальное решение, которое на голову лучше всех остальных? Нет, но хотя бы мы понимаем, где у нас trade-off’ы.

А дальше, оказывается, что и все равно надо больше, прости, Господи, гуманитарных технологов, потому что все понимают в этом governance про то, как приходить к результату выборов, но никто не понимает из технологов, откуда вообще берутся вопросы, которые стоят и не стоят голосования. И самая большая уязвимость большинства систем governance, которые я видел, это курирование повестки следующих выборов и т.д.

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

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

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

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

Кирилл Пименов: Ну, давай, когда мы передаем с нашего горячего кошелька на сайнер транзакцию, мы будем говорить. А кстати, я сейчас разговариваю про метаданные вот с таким вот root hash-ом. И сейчас я буду передавать тебе байтики, и каждому сегменту байтиков я буду предлагать тебе Merkle-ветку от нашего hash-а, про который мы договорились.

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

Ты можешь забыть Merkle-веточку метаданных, я тебе их снова пришлю, когда в следующий раз понадобится снова знать там про… Ну, предположим, у нас batch-транзакция, мы 10 раз переводим стейблкоин, это один и тот же стейблкоин, но я пришлю тебе 10 раз его десятичную позицию, и у меня не отвалятся руки, а тебе зато не надо все метаданные хранить, и как-то из них чего-то доставать, потому что ты несчастный маленький аппаратный кошелечек, у тебя килобайты оперативки, и лучше все стримить, а не сохранять.

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

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

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

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

Это все ломается, когда у нас начинается более свободное изменение смарт-контрактов, когда не надо никакого governance, когда нет никакой централизованной метаданных. И это вот та серьезная реалия, в которой мы живем в EVM. Нам с одной стороны у нас нету обновления runtime’ов, поэтому мы не то что конкретную метадату сегодняшнюю не можем туда закоммитить, у нас нету даже механизма, чтобы подписи проверялись теперь опционально вот таким вот новым способом с метаданными включенными куда-то.

И это абсолютно невозможно никакой форк провести, который бы это требовал просто out of scope любого проекта, который над этим бьется. Соответственно надо придумать что-то другое, надо придумать какой-то способ, чтобы транзакция, которую мы подписали в конечном итоге включала в себя еще вот какой-то набор этих ассертов.

Это похоже на две штуки, это похоже на account abstraction и это похоже на Flashbots. Вот где-то вот здесь мы и пытаемся нащупывать самые изящные решения, которые будут на всех EVM-ах работать.

Сергей Тихомиров: Почему это похоже на account abstraction?

Кирилл Пименов: Потому что account abstraction как раз нужен для того, чтобы твоя транзакция на самом деле триггерила какую-то внутреннюю EVM-машинерию, чего-то там вычисляла, а не просто переводила деньги с счета A на счет B. И при этом как бы эта машинерия может быть неявным способом включена в твою транзакцию.

Это единственный вообще способ что-то делать неявное с транзакциями на Ethereum блокчейне. Они очень ценят свою обратную совместимость, поэтому транзакция, которая делает трансфер, она делает трансфер. Просто если у тебя адрес исходящий, это account abstraction адрес, то мы делаем еще что-то.

К сожалению или к счастью в account abstraction нельзя положить абсолютно любое вычисление, там достаточно большое количество жестких ограничений на то, чего вообще и каким даже ячейкам знания о блокчейне account abstraction contract может обращаться.

Вторая досадная неловкость здесь, это то, что account abstraction сначала надо задеплоить. То есть тебе, чтобы начать работать с кошельком, тебе надо его как-то инициализировать. Ты не можешь просто взять адрес, на него получить, что-то отправить.

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

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

Но вот у нее было бы вот это вот дополнительное свойство, потому что оно на какие-то дополнительные допущения опирается, и если эти допущения не верны, то она не выполнится.

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

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

Сергей Тихомиров: Давай, наверное, про другое немножко поговорим, про другой аспект архитектуры сайнера, который, мне кажется, необходимо осветить. Опять-таки, у меня, возможно, устаревшие какие-то представления, но в моей картине мира есть такая вот вечная дихотомия или вечное противостояние архитектуры сайнеров, используют ли там secure element или нет, и как его правильно использовать.

Насколько я понимаю, готовясь к этому выпуску, я осознал, опять-таки, поправь меня, если мое представление неправильное, что на самом деле и Trezor, и Ledger, и, возможно, другие производители, они как-то унифицируют более или менее свои подходы к этому вопросу, и топовые модели используют secure element так или иначе, в чем-то все или многие.

Кирилл Пименов: Нет, тут есть некоторая забавная тонкость, которая состоит в том, что когда ты ставишь secure element, у тебя начинает быть очень ограниченный выбор криптопримитивов, в которых ты можешь там ключами шевелить. В частности, ну вот, самый-самый очевидный пример – это какая-то IOTA, где там троичное свое собственное шифрование.

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

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

Сергей Тихомиров: Сейчас, давай остановимся здесь подробнее. Вот есть… сейчас я соображаю, с какой стороны правильнее подойти. Давай, наверное, подойдем со стороны Kampela все-таки. Расскажи, пожалуйста, как в Kampela это устроено, есть ли у вас secure element и как, собственно, вы обходите его ограничения, если они вам мешают, как вот вы выстраиваете взаимодействие между secure element и процессором, который… ну как бы обычный процессор без защищенного криптографического enclave.

Кирилл Пименов: Мы угорели как бы надменно и решили, что блокчейны, которые требуют чего-то, что не умеет наш enclave, мы, скорее всего, поддерживать никогда не сможем и не поддерживаем. Вот. Это не бесплатный trade-off, я очень понимаю проекты, которые делали что-то по-другому, но в текущем продуктовом виде Kampela мы хотели бы видеть безопасность бескомпромиссной, и поэтому мы решили, что да, вот у нас есть хороший чип, на самом деле два чипа под одной крышечкой, один чип – это общий чип, а второй – это как бы secure element, который в него вставлен.

И у STM, и у ESP есть в линейке всегда такие чипы. У нас большой инженерный документ, который посвящен внутренним рассуждениям на то, как бы лучше сделать все под одной крышкой, или лучше сделать два чипа, и какие у этого плюсы и минусы. Это может быть пересмотрено, с точки зрения логики разница не очень большая.

У нас есть secure element, он умеет вот это, вот это, вот это, вот это, мы можем его научить только, только мы еще там совместимы к secp256 и прочим понятным известным общеиспользуемым алгоритмам. Если у вас что-то особенное, извините, вы как-то, ну т.е. вы не сможете от этого железа получить эти же гарантии безопасности, и нам кажется, что гораздо важнее эти гарантии безопасности соблюдать, тем более что мы опенсорсные, и соблюдение и несоблюдение этих гарантий у нас легко посмотреть.

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

И мы делаем, да, только те примитивы, которые у нас есть, и поэтому наши ключи, действительно, наш secure element никогда не покидают.

Вопрос дальше, какой, ну типа как мы очерчиваем границы этого secure элемента, используем ли мы дополнительно у ARM есть там эти самые trust-зоны, т.е. возможность разместить кусок основной памяти тоже под secure элементную память, которая будет где-то там куда-то аппарат нашифровываться. Но в целом идея такая, ну если мы пытаемся…

Сергей Тихомиров: Sorry, follow-up вопрос. Правильно ли я понимаю, что все-таки secure элемент предлагает некоторое доверие к производителю этого чипа? И, видимо, как я понимаю из того, что ты говоришь, какой-то консенсус существует в том, что эти trade-off’ы нужно брать и что преимущество того стоит? Или я чего-то не понимаю?

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

Intel SGX – это настолько успешный проект, что им с какой-то ревизии процессоров они просто перестали добавлять SGX в свои клиентские девайсы. Они все еще для серверной совместимости его куда-то в серверные версии добавляют, а в потребительских десктопных SGX больше нет, потому что не получилось.

В целом мы наблюдаем, что Intel немножечко идет к закату, и хорошо, что у нас народилось некоторое количество альтернатив к ним. При этом, кажется, что чем проще процессор, и чем проще его криптографический security co-processor, тем лучше. Чем дальше у нас расстояние между людьми, которые дизайнят архитектуру и людьми, которые действительно делают чипы, тем лучше.

В этом смысле ARM, наверное, лучше, чем какой-то Intel или AMD, потому что ARM дизайнит, а имплементируют уже другие.

Сергей Тихомиров: Подожди, а почему лучше, когда разные люди дизайнят и имплементируют?

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

Сергей Тихомиров: Просто я предполагаю, что можно с другой стороны на это посмотреть, если ты, как написано на iPhone’ах, наверное, не было iPhone никогда, «Designed in California, made in China», если ты дизайнишь в Калифорнии, а потом отправляешь на производство в Китай, то фиг его знает, что там на китайском заводе по приказу компартии произойдет. Можно и так поставить вопрос.

Кирилл Пименов: Это безумно интересный вопрос. Я лично знакомому, кстати, подарил одну из Kampela такому чуваку, который называется Bunnie Huang. Это чувак, который сделал телефон Precursor. Сейчас у него есть проект инфракрасной интерферометрии спектроскопии, что ли. Как это описать? Он светит инфракрасной лампой на чипы, и по интерференционной картине пытается понять, что там внутри, и совпадает ли этот чип с этим non-invasive.

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

Поэтому есть некоторый набор подходов. Давайте я вспомню, как проект называется, и мы его добавим куда-нибудь под выпуском. Безумно интересная штука. В том числе он оптимизирован под Do It Yourself, в целом купить за там где-то тысячу евро компонентов и сам у себя эти чипы валидировать.

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

Кирилл Пименов: Ну, это постоянная война. Это штука, которая не имеет решения настолько, что мы пытаемся, по сути, скорее всего, для продакшена мы прямо склеим две Kampela в одну, и у нас будет Kampela, которая отвечает за экран, и она не перепрошиваемая, и Kampela, которая отвечает за всякую блокчейновую требуху, в которой можно дополнительные прошивки ставить. Потому что если… Ты не можешь secure enclave’ом контролировать экран.

Слишком много всего надо тебе вычислять. Памяти надо много, ну, по embedded меркам, то есть тебе надо весь экран в этих точках представлять, и куда-то копировать из места в место. А enclave вообще крошечный. Если enclave не крошечный, то там дыры. Поэтому ты хочешь самый маленький enclave из всех возможных. Если он крошечный, то он экран не контролирует.

Сергей Тихомиров: Интересно. Опять-таки это рассуждение, которое тоже я читал много раз еще, раньше, когда изучал эту тему, что вот криптографический enclave может только очень маленькие количество операций сделать. Почему не сделали enclave побольше, или пытались и не получилось, как в случае с SGX? Спрос вроде есть.

Кирилл Пименов: У них есть фундаментальные проблемы с увеличением. Это правда. И мы пытаемся разными подходами так или иначе все это надувить. В том числе мы пытаемся на уровень дата-центра это раздуть. И это технология, которая меня в платежке очень интересует. Как можно использовать secure enclave, надуть trust-элемент до полного Docker-контейнера.

Подходы есть. Они чудовищно сложные. Такая машина Руба Голдберга. Что-то такое мы пытаемся делать. И это все хардверные инженеры планеты, которые занимаются trust-компьютингом, они про это сейчас очень активно думают.

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

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

Ну а они как бы не уделяют достаточно внимания, потому что они хотят поддерживать разные странные нестандартные шифрования. А это значит, что у них в любом случае ключ вообще покидает enclave в каком-то виде.

Сергей Тихомиров: Что делает Ledger?

Кирилл Пименов: Ledger не позволяет тебе свои собственные прошивки на Ledger запускать. Тебе надо показать свою прошивку Ledger Security Team, и они только разрешат. И что они в первую очередь проверяют? Это они проверяют, что ты не пользуешься рутовым ключом, а ты из enclave достаешь только деривацию, которая соответствует твоему блокчейну.

И там есть эта гигантская табличка, что для Ethereum у нас вот такое, для Polkadot у нас вот такое, поэтому прошивку Polkadot’а она сможет, если что, сбежать с ключом от Polkadot’а, но это никогда не компрометирует ключи от Ethereum и прочего.

И это, кстати, ровно то security допущение, которое они ослабили, когда они пытались сделать Ledger Recover, потому что, конечно же, чтобы сделать Ledger Recover, надо было полный корневой этот ключ достать в общую память и что-то с ним там поделать. И даже если он там по Шамиру в трех посылках потом на три разных адреса с ровно отправлялся, так или иначе, это сильное ослабление модели безопасности. И они за это получили совсем на редизайн или нет.

Сергей Тихомиров: То есть вот в этом Ledger Recover я правильно понимаю, что это не то, что seed-фраза подписывается внутри enclave и только… не подписывается, сорри, шифруется внутри enclave под моим паролем и только в зашифрованном виде его покидает, а она покидает его в plaintext.

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

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

Сергей Тихомиров: Окей, так хорошо, а что Kampela тогда насчет соединения с экраном, оно происходит все равно через незащищенный получается кусок процессора?

Кирилл Пименов: Да, это так. Да, это одна из проблем. Да, это то, почему мы максимально сопротивляемся тому, чтобы Kampela вообще была перепрошиваемая. Потому что если бы моя Kampela была хорошо перепрошиваемой, я бы ее сейчас бы уже продавал с тем, что Ethereum, Coming Q3 2025. Проблем нет вообще. Поскольку нам надо очень много всего зафронтлоадить в места, которые мы аппаратно запретим перепрошивать. У всех процессоров есть натуральные перемычки, ты ее как-нибудь вольтажом пережигаешь, и вот эти места в прошивке перестают работать. То есть перепрошивочные API перестают перепрошивать. И это требует очень и очень внимательного дизайна, и мы не можем этот дизайн финализировать, пока мы не поймем до конца, как вот эта вот история с метаданными перепрошивки.

Одно из решений, на мой взгляд, сильных, но сильно-сильно мешающих в цене retail, это тупо поставить второй процессор. И один процессор пусть отвечает за экран, а второй процессор пусть отвечает за NFC и связь с внешним миром. И тогда у тебя будет все приходить по недоверенному процессору, там паковаться в понятные API, прогонять через enclave и вылезать через второй процессор на экран, а тот процессор уже не перепрошиваемый.

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

Сергей Тихомиров: Sounds like a plan, я не знаю, звучит довольно разумно.

Кирилл Пименов: А это требует второго чипа, это удорожает BOM на 15% сразу, потому что тебе надо 2 приблизительно одинаковых процессора ставить. Ну и понятно, что на производстве тебе их надо флешить, тебе надо больше quality control, чего только не надо. Очень может быть, что мы такое сделаем, а да, это самое потребление питания сразу повышается, ну там большое количество trade-off’ов, может быть мы найдем что-то более изящное, но если что у нас в запасе есть сильное решение, которое к сожалению сделает нас дороже Ledger’а входного уровня. Ну кто там, Nano S+, они сейчас продают как самые дешевые за 100 долларов, к сожалению, тогда мы в 100 долларов не уместимся. Но в целом это валидное размышление, да, хотелось бы, чтобы с момента того, как данные попали в secure enclave, все, что оттуда выливается, шло бы только по доверенному тракту, that’s the point.

Нам еще несколько легче, потому что кроме перепрошиваемости, неперепрошиваемости, у нас еще аппаратного доступа ко всему этому практически нет, мы обладатели довольно уникальной технологии литья эпоксидки прямо на печатные платы, это нетривиальная технология на самом деле, единственный массмаркет девайс, который такой умеет делать, это Yubikey, и даже их основной конкурент Nitrokey делают сборные корпуса, это нетривиальная проблема чисто по физическим причинам, у тебя эпоксидки когда застывают, либо стягиваются, как зажимаются, и там прям на десятки процентов иногда, либо они греются, то есть они либо экзотермические, либо сдуваются, и если она сдувается, она начинает срывать компонент с твоей печатной платы просто за счет механических напряжений, а если она экзотермически оседает, то там могут возникнуть кармашки нагревания, которые отпаяют твои припаянные платы, а поскольку это твоя плата уже припаянная и уже залитая эпоксидкой, ты не можешь даже сделать то, что обычно в обычном производстве электроники делают, если quality control не прошел, они тупо кверх ногами эти платы ставят в печку, все детали падают вниз, их дальше сортируют, каждую отдельно QC’ят, и в новые девайсы ставят по кругу, а у тебя ты сразу в шредер такой, бру, и весь твой BOM со всей полной ценой вообще никому больше нафиг не нужен, потому что у тебя один конденсатор отпаялся, там перепаялся криво.

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

Сергей Тихомиров: То есть получается, что в других сайнерах, например, в том же Ledger, поскольку он не залит целиком, у него внутри есть воздух, технически можно его разобрать, вставить что-то внутрь, и запаковать обратно, так что никто не заметит по крайней мере без…

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

Сергей Тихомиров: Даже 2018, я больше скажу, у нас даже был про это выпуск, когда готовился, я посмотрел, собственно, этот доклад, который ты кинул в наш чатик выпуска, и выпуск базового блока 053, где я пересказываю этот доклад про Wallet Fail.

Кирилл Пименов: Ну и ты же помнишь, что там чувак раздавал со сцены натурально ну и эти самые перемычки для кнопок Ledger, которые позволяли по 433 МГц нажимать на кнопки удаленно.

Ну вот, как бы у меня где-то была, я ее то ли посеял, то ли она в лабе осталась, но там как бы особо ничего нету, там просто чудеса миниатюризации. Поэтому да, то есть этот корпус Ledger в целом можно разобрать, и если хорошо сделать, то можно разобрать бесследно, что-то туда как бы вкорячить, там есть воздух, известная история про то, как Apple разрабатывал при Джобсе iPod, вот, и ему принесли девайс, он говорит как бы, вы все меня обманывали? Они такие, да, точно-точно все меня обманывали, меньше нельзя сделать, все, да, он берет, кидает iPod в аквариум, из него выходят пузыри, видите, там был воздух, идите миниатюризировать дальше.

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

Кирилл Пименов: Значит, это не видно радиослушателям, но мы пожертвовали размером и радионаглядности. Наша печатная плата односторонняя, и она полностью, ну, как бы, задокументирована прямо вот с точки зрения не только принципиальной схемы, но и разводки у нас на GitHub. Вот, и при желании можно это открыть. Я не помню, рендерим мы сейчас это в PDF или только у нас есть KiCad’овские файлы, которые можно открыть в KiCad’е и посмотреть, но это, кажется, и то, и другое дело техники, потому что KiCad опенсорсный можно бесплатно его на любой компьютер поставить.

Вот, и да, можно элемент за элементом сравнить то, что у тебя здесь, и то, что у тебя там, потому что мы заливаем ее прозрачной эпоксидкой, краской не красим, и у нас все кишочки наружу. И в частности, можно убедиться, что на ней, и это вот как бы тоже почему мы ломаемся про второй микроконтроллер, у нас все на свете сделано в дискретной логике. У нас ровно два программируемых места. Это not a given для большинства электроники, потому что проще делать крупноблочно из вещей под управлением микроконтроллера.

Сергей Тихомиров: Нужно больше background’а, расскажи, пожалуйста, про этот выбор. Для меня совершенно не очевидно, зачем так, кто сейчас произнес.

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

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

И у тебя вот эта программа отвечает за управление питанием, а эта программа у тебя отвечает за радиосвязь, а вот это вот отдельный чип, который делает тебе NFC, и вот они вот все чипы в том смысле, что они умные большие микросхемы, у которых на борту есть какой-то код, который closed source, откуда он туда пришел, перепрошиваемый или нет, абсолютно неизвестно.

И мы упоролись и решили это минимизировать, и поэтому у нас, например, нету NFC-чипа, вообще у нас нету микросхемы, которая умеет реализовывать NFC. А поскольку Kampela не имеет by design внешних проводов, звездочка девкиты имеют, потому что тебе надо как-то после неудачной перепрошивки ее реанимировать, поэтому там есть разъем для программатора. Retail не будет иметь таких портов. И поскольку она питается от NFC и свою информацию о транзакции получает от NFC, и никаких разъемов у нее нету, то нам надо как-то реализовывать NFC, и мы реализовали его на дискретной логике, которая биты гонит прямо в основной процессор, в основную прошивку.

У нас нету отдельной… Наша жизнь была бы гораздо более проста, и debug нашей прошивки был бы гораздо более тривиален, если бы мы так не делали. Но тогда бы у этого чипа теоретически была бы возможность ту же самую антенну раскачать в ответ и послать радиосигнал обратно. А Kampela вообще не умеет, не имеет технической возможности издавать радиосигналы.

Сергей Тихомиров: Да, вот этот интересный очень аспект, мне хотелось тоже прояснить, давай, может быть, еще на минуту здесь остановимся, т.е. в вашей документации я прочитал, что в Kampela односторонний NFC, т.е. она получает информацию посредством NFC с условного телефона, но ничего не может отдать. Я думал, как же это реализовано. Если бы вы хотели по простому пути пойти, вы бы взяли какой-то off-the-shelf компонент, общедоступный, и там была бы реализация NFC в две стороны. Вы можете использовать там, окей, но кто пишет этот код, как он там взялся и можно ли его подменить? Открытый вопрос. А вы вместо этого взяли только тот кусок логики, который нужен вам, работа только на прием, без передачи. И прямо его в хардвере имплементировали без опоры на какие-то внешние компоненты софтверные от кого-то?

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

То есть, все, что превращает NFC из аналоговых радиоволн в понятный процессору цифровой сигнал у нас сделан дискретной логикой, вот именно отдельными наборными компонентами, которые мы ставим на плату на нашей производственной линии. И этим мы, а с одной стороны, нет на рынке NFC-чипов, которые односторонние, потому что вообще-то NFC – двуходносторонний протокол, он не умеет, он как TCP, ему нужно как минимум Ack-пакеты обратно посылать. А с другой стороны, мы уменьшили количество мест, которые в целом несут в себе security risk.

Сергей Тихомиров: Отправляющей стороне окей, что она Ack-пакеты не получает?

Кирилл Пименов: Нет, если она не получала бы Ack-пакеты, то, к сожалению, вся штука совсем не работала. И поэтому у нас в нынешней итерации Kampela прямо встроена такая маленькая пластиковая квадратная штучка, которая на борту несет самая-самая дешевая за 50 центов NFC-чип, который говорит все время «Повторите погромче, я вас не услышал». На любой входящий. Все. Она больше ничего не делает, и она физически никак не связана с остальной Kampela.

И эта штучка нужна для того, чтобы надурить твой телефон, передавать-таки информации, потому что иначе, в противном случае он что-нибудь кинет, услышит, что там его никто не услышал, и соображение не экономит энергии, особенно на iPhone этим грешат. И они очень-очень экономны к энергии. И вряд ли можно быть более экономным, вообще, респект этим инженерам, но этот механизм надо как-то обмануть, чтобы она достаточно долго и продолжительное время кричала радиоволнами в общую сторону Kampela, чтобы Kampela могла эти радиоволны использовать для того, чтобы шевелить e-ink точечками на нашем прекрасном touch экране.

Сергей Тихомиров: То есть получается, что ну, строго говоря, какой-то NFC-сигнал идет и в другую сторону тоже, но он не зависит от payload’а, он просто всегда говорит: говорите громче.

Кирилл Пименов: Да, и он идет не из Kampela, он идет из отдельного внешнего девайса, который при необходимости можно подменить на любую другую карточку с поддержкой NFC и Mifare A.

Сергей Тихомиров: Ага, вот теперь теперь, мне кажется, я несколько лучше понял, что, собственно, ты демонстрировал на демо, ссылку на который мы приложим в описании видео, где ты показываешь, как работает. И вот этого момента я не понял, сейчас, наверное, я понял немного лучше, как вот ты в одной, значит, жонглируя тремя девайсами сопоставляешь, значит, телефон, карточку проезда на берлинский транспорт и Kampela. Я подумал, а при чем здесь вообще Deutsche Bahn, да, и BVG?

А это для того, чтобы… Сейчас, вот я попробую объяснить, да, что, значит, вот эта карточка, она телефону говорит, передавай еще. Откуда карточка знает, что это нужно говорить?

Кирилл Пименов: Ну, телефон же говорит то, что Kampela понимает, а все остальные это не понимают, и поэтому они типа, что ты мне сказал, повтори. Это случайный приятный side-эффект того, что мы не говорим в том языке, который…

Сергей Тихомиров: Понял, то есть карточка слышит, что есть, что вот и говорят, но они не могут это расшифровать, потому что это для Kampela, а не для карточки. И карточка говорит, повтори.

Кирилл Пименов: Ну, да, ну, как бы смысл из этого извлечь, да.

Сергей Тихомиров: Окей. Сейчас, а как так получается, чтобы ответ на этот, значит, когда карточка или вот этот съемный модуль Kampela говорит, повтори, телефон передает следующую часть сообщения, а не повторяет уже предыдущую? Или там все сообщение одним куском идет?

Кирилл Пименов: Ну, там как бы странный вот этот протокол, который поверх NFC NDEF, стандарты сделан, который пытается, да, вот сделать, как бы, этот канальный TCP из UDP, если как бы такая аналогия уместна здесь, с большим натягом, но да. И смысл в том, что да, это просто посылка датаграмм и какая-то реакция на них, и там странным образом перемешиваются вот именно как бы этот аппаратно-канальный уровень и семантический, потому что все, что нас учили про модели OSI на семи слоях, это на самом деле некоторая абстракция, и как только ты начинаешь реальные радиопротоколы дизайнить, у тебя все слои слипаются.

Сергей Тихомиров: То есть получается, что нормально, если там есть, если протокол предусмотрен, нормальный Ack в ответ, мы его послать не можем, потому что он как-то закоммичен к payload’у, который пришел на устройство.

Кирилл Пименов: Я если сейчас не супер, как бы сейчас вот из головы могу ответить, как именно с точки зрения пакетов там это реализовано, и мне надо будет немножко либо в код посмотреть, либо Flipper’ом это потыкать.

Сергей Тихомиров: Просто для меня не очевидно, почему мы обратно передаем сигнал повтори еще, а не просто передаем сигнал, понял, принял, шли дальше.

Кирилл Пименов: Может и понял, принял, если честно. Вообще неважно, потому что на стороне отправки ты в общем контролируешь, что ты дальше шлешь, и это тоже как бы сложность, потому что Android любой шлет достаточно этих пакетов, чтобы питать Kampela, а Apple начинает думать, что происходит какая-то фигня, и тебе нужно специальное приложение, даже чтобы повторять их с достаточной частотой, чтобы Kampela раскачать. Это то, почему я, когда ее демонстрирую, мне сложнее с Apple’оводами, потому что им надо там чего-то куда-то из TestFlight и прочих вещей.

Но тут важно сказать, что как минимум мы используем вот самый тупой NDEF протокол и не используем никаких этих NFC payments API и так далее настроек над ним, которые требуют дополнительной там верификации с Apple’ом и прочих разрешений. Самый-самый тупой это вот то, чем работают самые все NFC токены, которые у вас есть, карточки на проезд, бывают музеи, где можно телефон приложить и он тебе там набубнит в ухо что-нибудь про экспонат. Вот как бы это тот протокол, который мы используем абсолютно общедоступный и понятный.

Сергей Тихомиров: Ну и тогда знаешь, так завершая что ли обзор типичного flow, который юзер проходит, используя Kampela, вот у меня есть payload, который сформирован моим, допустим, телефоном, к нему приложен Merkle root metadata, который обеспечит, ну понятно, то, о чем мы говорили в первой части разговора, и это посредством NFC шлется на Kampela. Kampela это подписывает и показывает подписанный payload в виде QR-кода на экранчике. Вот давай осветим этот аспект.

Кирилл Пименов: Единственный способ информации которая могла бы использовать для того, чтобы покидать Kampela, это экран. Это вот как бы физику… Мы надурили физику, чтобы она на нашей стороне работала в обеспечении безопасности ваших ключей. Потому что ну если я втыкаю куда-то USB, я, если честно, вообще не в курсе чего там, куда, в какую сторону идет. И никакого общедоступного и понятного sniffer’а нету. Ну то есть как бы есть большое количество там супер нердовских штук, но предлагать их использовать, это ну типа как этот… Дебажить даже не в Visual Studio, а вот в этом старом добром GDB с управлением с клавиатуры в терминале.

Вот такого вот уровня никто никогда не сможет этим пользоваться для… чтобы убедиться, что его аппаратный ключ USB подключения не тырит ключи и не рассказывает их по одному битику в подписи на протяжении двух лет. Это гораздо проще, когда у меня есть экран. Экран содержит QR-код. QR-код имеет только те биты, которые ты ждешь. И ты можешь любой независимой камерой этот QR-код сосканировать и убедиться, что там то, что ты ждешь, ничего больше.

Сергей Тихомиров: Подожди, а почему QR-код не может по биту за подпись сливать приватный ключ? Наверняка же там есть какой-нибудь инициализирующий вектор рандомный, его в принципе можно было бы подбирать не совсем рандомно.

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

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

А поскольку мы используем e-ink в дисплее, то этот QR-код на экране в общем остается бесконечное количество времени, и у тебя есть все время мира, чтобы с ним что-то поделать. Потому что в момент, когда ты подписал эту подпись на экран, вывел, вот она там, ты можешь что-то с ней делать, столько, сколько хочешь, а девайс уже умер.

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

Понятно, что не во всех местах user flow нам нормально, что то, что сейчас мы видим на экране, остается на экране навечно. Например, если бы там была seed-фраза, я бы хотел, чтобы она стиралась. Поэтому, да, мы следим за разрядом батареек, и когда у нас хватает ровно на один полный wipe экрана, мы сверяемся с состоянием памяти, и если там отмечено, что экран секретный, то мы из последних сил просто его wipe’аем. Но в большинстве мест в прошивке такого не надо.

Сергей Тихомиров: Но в целом, я как юзер могу что-то нажать, чтобы очистить экран после того, как я сосканировал.

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

И завершая эту часть нашего разговора, я еще раз хочу поблагодарить тех, кто поддерживает наш подкаст. Это наши патроны на Patreon, Boosty и Yoki Finance, а также это наши спонсоры Fluence, децентрализованная облачная платформа, Acki Nacki, the fastest blockchain possible, 1inch, лидер в DEX агрегации, и Zerion, Enterprise Grade Web3 API. До следующего выпуска. Всем пока.