(00:00:00) Егор Хомяков: Слово «блокчейн» появилось совершенно случайно и ни разу не использовалось в whitepaper Bitcoin.pdf. Ничего общего с цепочкой блоков это не имеет. Важно вернуться до появления биткоина и начать видеть мир через призму стейт-машин. XLN — это сочетание четырех видов блокчейнов. Я отказываюсь называть его словом «блокчейн».

(00:00:21) Сергей Тихомиров: Всем привет, с вами подкаст «Базовый Блок», подкаст про блокчейн. У микрофона сегодня я, Сергей Тихомиров, и мой соведущий Иван Иваницкий. Привет, Иван.

(00:00:32) Иван Иваницкий: Привет, Сергей.

(00:00:33) Сергей Тихомиров: А в гостях у нас сегодня Егор Хомяков, архитектор XLN. Мы поговорим про эволюцию платежных архитектур и платежных каналов. Не уверен, можно ли так называть эту архитектуру. Также про кредиты, архитектуру глобальной платежной системы для всего человечества и о том, как её правильно задизайнить. Егор, привет! Спасибо, что зашёл.

(00:00:52) Егор Хомяков: Спасибо, что пригласили. Очень рад с вами пообщаться.

(00:00:56) Сергей Тихомиров: Взаимно. Прежде чем мы перейдём к разговору, говорим спасибо нашим подписчикам и патронам на patreon.com/basicblockradio и boosty.to/basicblockradio. Также спасибо нашим спонсорам.

(00:01:06) Сергей Тихомиров: Наши спонсоры — это Fluence, облачная платформа на базе децентрализованной инфраструктуры, которая предоставляет более дешёвую и отказоустойчивую альтернативу традиционным облачным решениям, таким как AWS, Digital Ocean или Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру, при этом значительно снижаете расходы и не зависите от одного провайдера. Большое спасибо Fluence.

(00:01:36) Сергей Тихомиров: А также нас поддерживает Zerion, Zerion API, мощный инструмент для Web3-разработчиков. С его помощью можно в реальном времени получать данные о кошельках, токенах, DeFi-позициях и NFT на более чем 24 блокчейнах, включая Ethereum, Solana и другие. API предоставляет детальные, человекочитаемые транзакции, мультичейн, аптайм 99,9%, масштабируемость выше 1000 запросов в секунду. API Zerion используют такие компании, как Uniswap, OpenSea, WalletConnect, Rainbow Wallet и другие.

(00:01:57) Сергей Тихомиров: Нас также поддерживает GOSH, кор-разработчик блокчейна Acki Nacki, основанного на новом протоколе, достигающем консенсуса за две итерации, самым быстрым из теоретически возможных. GOSH уже запустил Mainnet. Добавлю: у нас был выпуск 212, послушайте, если интересно. В коммьюнити более 4 миллионов участников. Заключены партнёрства с Oracle и Amper Computing. Основные направления развития: мобильный гейминг, biodiversity-активы, мемкоины и DePIN.

(00:02:32) Сергей Тихомиров: Также нас поддерживает 1inch, ведущий DeFi-проект и лидер DEX-агрегации с 23 миллионами пользователей и суточным оборотом более 1 миллиарда долларов. Нужно обменять токены между сетями — Ethereum, Polygon, Arbitrum и другими — 1inch найдёт лучший курс, заблокирует MEV-ботов и проведёт кросс-чейн-своп. Защитит от MEV и просто сделает свою работу. Свопай там, где это имеет смысл. 1inch.io. Большое спасибо нашим спонсорам.

(00:03:00) Сергей Тихомиров: А теперь перейдём к разговору с Егором Хомяковым. Привет ещё раз. Наверное, начнём с апдейта. Ты уже был у нас в гостях в стародавние времена. Я посмотрел в архивах: это выпуск номер 80, записанный в 2019 году. Тогда мы тоже говорили про платежные каналы, кредиты и перспективы Lightning. Расскажи в двух словах, чем ты занимался последние несколько лет и как, возможно, поменялся твой взгляд на развитие блокчейн-технологий?

(00:03:29) Егор Хомяков: Во-первых, я перестал смотреть на это как на развитие блокчейн-технологий, потому что считаю: нужен zoom-out, и нужно смотреть, как ты вначале сказал, на развитие финансовых систем в целом. Это критически важно. Самая корневая идея — соединение кредита и collateral, как было в 2019 году. Кстати, я залил в нейронку весь транскрипт нашего диалога, потом залил текст в LLM и спросил, что изменилось. Это совпало с тем, что я хотел сказать. Поэтому я их обожаю. Как ты, конечно, жалуешься, что я их использую, но извини: пока это единственные сущности, которые меня понимают процентов на девяносто.

(00:04:10) Сергей Тихомиров: Мы поговорим ещё про это ближе к концу.

(00:04:11) Егор Хомяков: Скажем так, на тот момент моё видение было всё ещё ограничено тем же нарративом, связанным с Lightning и каналами. Я вообще использовал ту же терминологию, и этим ограничивалось то, как это можно было применить. Следующие пять лет, on and off, я реализовал то, что тогда хотел сделать. У меня был JavaScript-код, но он был недостаточно хорош, чтобы запускать на Mainnet. Я знал, как его можно сломать. Даже не со стороны security, а в том смысле, что архитектурно, когда ты делаешь сеть с множеством одновременных параллельных взаимодействий — не как в блокчейне, где есть блок, изменение, стейт, к которому ты пришёл, опять блок, и это всё довольно легко протестировать — когда у тебя много движущихся частей, нужен совсем другой подход к архитектуре. Мы это позже обсудим. Я нашёл способ сделать это правильно.

(00:04:37) Егор Хомяков: Ключевая вещь, которая поменялась: я понял, как это можно реализовать и как добавить то, чего на тот момент не хватало. Я больше не использую слово «канал», использую слово «аккаунт». Это программируемость взаимодействий внутри аккаунта и программируемость сущностей по обе стороны аккаунта. Чтобы это была не просто Алиса и Боб, а могли быть сложные многокомпонентные DAO. Это были два основных слепых пятна, в которых роллапы и другие решения на тот момент были лучше.

(00:05:25) Егор Хомяков: Релизить ту концепцию, которая была в 2019 году, можно было. Были бы быстрые платежи. Но к этому моменту роллапы уже более-менее стали mature, и они бы сказали: смотри, у тебя нельзя задеплоить, например, сейф Gnosis или какой-нибудь DAO Aragon. У тебя нельзя сделать AMM как Uniswap. У тебя нельзя сделать сложные lego-взаимодействия. И они были бы правы. В долгосрок на тот момент их DeFi-композитарность выигрывала. Все эти пять лет я крутил в голове мысль: как сделать то же самое, но со скоростью off-chain взаимодействий.

(00:05:58) Егор Хомяков: Я нашёл решение. И чтобы далеко не убегать, хочу, чтобы было back and forth, чтобы вы что-то отвечали, потому что я могу очень долго говорить в дебре.

(00:06:05) Сергей Тихомиров: Я не совсем понял вас в том, что вы сказали про то, как эволюционировала идея. Правильно ли было бы сказать, что ты ушёл от блокчейна как такового, как от центрального элемента своей архитектуры? Потому что для меня блокчейн звучит как некоторый якорь безопасности, который всё равно необходим и в rollup-конструкциях, и в платежных каналах. Мы всё равно обращаемся к нему за ультимативной безопасностью. Как ты на это смотришь? Тебе нужен блокчейн для новой архитектуры или нет?

(00:06:32) Егор Хомяков: Я отказываюсь называть его словом «блокчейн», потому что от слова «блокчейн» и от слова «каналы» мы отказываемся. Для меня терминология очень важна: от терминологии начинает строиться то, как ты относишься к вещам. По сути, XLN — это сочетание четырех видов блокчейнов. Если ты попытаешься называть блокчейн, юрисдикция блокчейна и так далее — сейчас вернёмся к описанию этих терминов — у тебя в голове ментальная модель будет совершенно испорчена. Каждый раз, говоря «блокчейн», ты будешь перебрасываться к стандартному определению в голове: Bitcoin, блоки, глобально и всеми повторяется. А тут блокчейны разного рода. Есть персональная и личная стейт-машина. Есть двухсторонние стейт-машины, видеокамп. Сейчас мы с нуля это открутим назад.

(00:07:11) Егор Хомяков: Важно вернуться до появления биткоина, до 2008 года, и начать видеть мир через призму стейт-машин. Основная стейт-машина, которая нас сейчас волнует, — это юрисдикционная машина. С этого момента мы так называем блокчейн. Слово «блокчейн» появилось совершенно случайно и ни разу не использовалось в whitepaper Bitcoin.pdf, если посмотрите. Кто-то просто сказал: давайте назовём цепочку блоков блокчейн. По факту ничего общего с цепочкой блоков это не имеет. Чтобы быть full node, тебе нужно хранить только последний блок, из которого уже растёт состояние. Это уже как минимум не цепочка, а один последний блок. А более подходящий...

(00:07:55) Сергей Тихомиров: Я тебя перебью здесь. Речь не о том, что обязательно должен полный нод всё хранить. Хотя тут можно поспорить, но спорить не буду. Идея в том, что у нас вся история складывается в цепочку блоков, и проверяя корректность каждого перехода, мы убеждаемся, что всё работает как положено. В этом и есть инновация.

(00:08:10) Егор Хомяков: Это механизм истории. А как назвать всю вещь правильно? Это реплицируемая стейт-машина. Даже если посмотришь whitepaper'ы по консенсусу — Tendermint и такого рода — они не используют слово «блокчейн», потому что когда ты серьёзным ресёрчем занимаешься, тебе просто неудобно им пользоваться. Ты сразу называешь это реплицируемой стейт-машиной. Они даже сокращают это как RSM.

(00:08:32) Сергей Тихомиров: Можно сказать, что стейт-машина — это некоторая абстракция, дальше есть её имплементация, а блокчейн и канонический список транзакций — это некоторый лог изменений, который в рамках правил этой стейт-машины произошёл?

(00:08:43) Егор Хомяков: Да, это механизм внутри истории. Для сравнения: есть просто машина на улице, и у неё четыре колеса. Называть машину «четырёхколесником» настолько же корректно, как называть эту юрисдикционную машину эфира «блокчейном», в моём понимании. Я считаю, что нужно хотя бы временно попытаться надеть эту ментальную модель, и вы увидите, что так просто удобнее смотреть на мир. Машина — нечто целостное, а «блокчейн» заканчивается на слово «цепочка». Мне так намного проще на эти вещи смотреть, хотя это вопрос терминологии. Дальше от этого мы сначала генерализуем понятие «реплицируемая стейт-машина».

(00:09:18) Егор Хомяков: А потом мы заявляем, что в разных видах использования оно решает разные проблемы. Юрисдикционная машина остаётся якорем — от этого уйти нельзя. Всегда должен быть якорь, в котором создаются ассеты, последний оплот правды, source of truth. Другого слова, кроме jurisdiction state machine, я не нашёл. Я думал о слове «депозитарий» или central bank, но слово central не в тему. Сейчас мы попробуем через этот примитив выразить все остальные существующие юрисдикции. Fed — это Центральный банк США, Банк России в России — тоже юрисдикционная машина, ещё до появления биткоина. Мы начинаем зум-аут на всю историю эволюции финансов на 7 тысяч лет назад, и первый появившийся центральный банк мы называем юрисдикционной машиной. Просто она single-signer, у неё единственный signer, и она запущена только на одном сервере. Но концептуально это то же самое, что Bitcoin и Ethereum. Мы должны видеть это как одну линию абстракций, как логистику, как layer 1.

(00:10:14) Егор Хомяков: И от этого уже строится система коммерческих банков, хабов. Их мы называем по-другому — машины сущностей, entity-машины. Они существуют под юрисдикцией юрисдикционной машины, привязаны к ней. Взаимодействие entity-машины с entity-машиной хабов уже может инфорситься в юрисдикционной машине. Пока мы рассматриваем период до 2008 года, инфорситься оно не может. Наша цель в XLN — создать возможность инфорсинга и эскалейта своих взаимоотношений с коммерческим хабом на уровень выше, в центральный банк, юрисдикционную машину. Направление дальше.

(00:10:52) Сергей Тихомиров: Юрисдикционная машина. Один из способов имплементации — Bitcoin или Ethereum как Layer 1 блокчейн, который менеджит своё состояние переходов и является source of truth для своей экосистемы. В централизованных традиционных финансах это центральный банк, который менеджит всех остальных. В роли коммерческих банков или, например, роллапов мапится на сущности, которые под этой юрисдикцией внутри себя что-то проворачивают, какие-то операции, обращаясь в юрисдикционную машину, когда это необходимо, но это далеко не всегда необходимо.

(00:11:29) Егор Хомяков: Final settlement. Две маленьких корректировки. В реальном мире, в традиционных финансах, так вышло, что во всех странах одновременно есть две юрисдикционных машины, даже несколько, и мы вынуждены их объединить и абстрагировать, чтобы не засорять ментальное пространство. Это центральный банк. Это Central Securities Depository — там управляются акции и разного рода регистры: на кого зарегистрирована квартира, какая-то земля. По сути это отдельные регистры, но для упрощения ментальной модели мы всё это оборачиваем в одну абстракцию и сжимаем в юрисдикционную машину. Условно, Банк России теперь хранит акции. На самом деле не было никакой технической задачи выделять брокеров от банков и Central Securities Depositories от центрального банка. Это настолько же бессмысленно, как хранить один ledger для всех фруктов и отдельный ledger для бананов. Мы просто забудем, что есть отдельные центробанки для акций.

(00:12:22) Егор Хомяков: Это первое уточнение. Второе: rollup — не совсем сущностная машина, они немного другого класса. Это тоже юрисдикционная машина, но которая оттачивается к юрисдикционной машине более высокого уровня, использует её как Data Availability Layer и отправляет туда свои блобы с информацией о том, что произошло на этой jurisdiction machine plus. Я это даже не рассматриваю как Layer 2. Хотя сейчас они немного монополизировали этот термин, и L2 равно rollup. Но на 90% ты верно всё сказал.

(00:12:48) Иван Иваницкий: Ты активно оперируешь термином «юрисдикционная машина». Можешь определить его, чтобы мы точно понимали его одинаково? Вернее, чтобы мы понимали его правильно.

(00:12:57) Егор Хомяков: Возьмём самую высокую абстракцию — replicated state machine, вообще как computer science абстракцию. У тебя есть некий Tendermint, который выполняет задачу каунтера, чего угодно. Потом мы начинаем его разделять на разные виды утилитарности, использований. Самый первый, основной — юрисдикционный: у тебя миллион нод или одна нода, неважно, но в которой рождаются деньги. В случае Банка России и Fed это одна нода, которая диктует всем остальным: мы только что напечатали такую-то сумму денег. В случае Bitcoin и Ethereum это миллион нод, сеть из валидаторов или майнеров, которые отвечают за создание новых блоков и их конфирмацию, и ещё сотни тысяч, которые перепроверяют те же блоки и убеждаются, что state transition произошёл корректно. Тот же source of truth, просто размазан по большему числу людей, которые перепроверяют. Это один из способов использования концепции replicated state machine. В XLN ещё три, помимо этого: runtime-машина, entity-машина и account-машина. XLN — это просто механический танец всех этих четырёх видов state-машин. Транзакции прыгают от юрисдикционной машины в entity, из entity через account-машины в другие entity. В этом красота: это очень легко дебаггить.

(00:14:09) Егор Хомяков: Потому что первая версия, которую я разрабатывал с 2017 по 2019 год, сделана приблизительно так же, как Lightning и Raiden. У тебя просто летают транзакции по вебсокетам, что-то к чему-то приходит, но ты не можешь зазум-аутить и произвести там условные 10 тысяч транзакций и прийти к тому же стейту. У тебя нет такого уровня интроспекции внутрь того, что происходит в сети. В XLN всё максимально детерминистично. У тебя есть Merkle tree, в который сворачивается вообще вся экономика. У тебя один хэш, из которого строится всё остальное, и ты можешь бегать тайм-слайдером как архитектор экономики. Это помогает быть уверенным, что ты разработал какую-то новую функциональность, и она работает правильно. Когда ты поменял код, ты просто сверяешь, что хэш сошёлся в конце. Вот для чего это нужно. Мы объявляем главную абстракцию — просто реплицируемая стейт-машина, — а потом говорим, что её можно использовать разными способами.

(00:14:59) Егор Хомяков: Юрисдикционная — это как раз классический блокчейн. Мы его не называем отдельно блокчейном: мы говорим, что это стейт-машина, которая имеет функцию юрисдикции, потому что там рождаются ассеты, она главная. Entity-машины уже коннектятся к юрисдикционной машине и говорят, что они имеют в ней свои счета. Некая entity-машина — моя личная, как Алиса, Боба, или как компании — имеет свой счёт в юрисдикционной машине. Она может скомпоновать транзакцию, и за счёт механизма inbox-outbox у каждой машины есть входящие и исходящие сообщения. Она может послать это сообщение в юрисдикционную машину, а та в ответ может вернуть какое-то событие через ивенты, которые Ethereum посылает через logpad, Recepts — по-моему, просто другими словами.

(00:15:41) Сергей Тихомиров: В чём цель всего этого упражнения? Цель — разработать, сформулировать что-то, чего ты пытаешься добиться этим проектом в целом?

(00:15:48) Егор Хомяков: Мы делаем ещё дальше зум-аут. Зачем вообще создавать всю эту сложность? Я считаю, что человечеству нужна классная, надёжная финансовая система. Сейчас мы живём в плане финансов в каменном веке. В традиционных финансах переводы безумно дорогие, всё работает на кастодиальных линиях, полнокредитных аккаунтах — я это называю так, сейчас покроем. Мы заслужили что-то лучше: с прогрессом в нейронных сетях мы получаем всё классное, современные девайсы, но почему столько страданий и болей мы должны испытывать, связанных с финансами, и в крипте, и в DeFi, и в CeFi? Моя цель — создать объединённую финансовую теорию, которая расщепляет обе эти линии, обе зоны на примитивы, и из этого создаёт суп из примитивов, которые решают те же задачи, но более элегантно и детерминистично, чтобы можно было, как я сказал, перепроиграть разного рода сценарий в браузере и потом задеплоить на большую сеть. Если совсем базово, я это называю правилом Triple S. Система должна быть максимально scalable, максимально secure и максимально simple — если вот самые простые метрики. В данный момент нет ничего похожего, никакой другой архитектуры, которая по всем трём фронтам имеет такие же высокие параметры Triple S.

(00:17:07) Сергей Тихомиров: Звучит вдохновляюще. Цель же не просто описать это с какой-то теоретической стороны, но ещё и реально построить, чтобы это было задеплоено в реальном мире.

(00:17:14) Егор Хомяков: 100%. Этим я занимаюсь каждый день и делегирую по возможности. Проект запредельной сложности. Самое хорошее понимание передовых нейронок и LLM's context — это всё, что спасает даже других людей, которые могут просто задать вопросы и получить внятный ответ. Цель — создать классную систему, которая масштабируется и которая безопасна. Что значит масштабируется? Это не 10 тысяч транзакций в секунду и не 100 тысяч. Это миллиард минимум. High-frequency trading — это уже миллион транзакций в секунду на какой-нибудь бирже, чтобы можно было за 100 миллисекунд, например, послать из Перу в Парагвай, в Китай и назад. Всё упирается в latency, speed of light. И это возможно только с unicast-системами. Unicast-системами сейчас в блокчейне и крипте не занимается вообще никто, кроме Lightning, который, я не знаю, делает вид, что существует, но мне кажется, уже на грани.

(00:18:00) Сергей Тихомиров: Под unicast-системой ты имеешь в виду систему, где не все знают про всё, а только участники транзакции знают про...

(00:18:06) Егор Хомяков: Да. Перевод ценностей представляет из себя точку, откуда ты хочешь послать, некое количество хабов — либо один хаб, либо два в большинстве случаев — и получатель. Это просто по интернету. Как работает интернет? Это unicast-система. Сейчас в мире есть всего две системы, которые масштабируются на всю планету и поддерживают условные миллиарды транзакций в секунду. Это интернет, вот как мы сейчас общаемся, и банковская система. Второй немного палки в колеса вставляют KYC и прочие старые интеграции, потому что там нет единого протокола. Они вынуждены использовать Visa, MasterCard, Swift, которые тоже довольно допотопные. Но в целом ограничений ни в миллион, ни в миллиард там нет — всё масштабируется. Только потому, что они математически сделаны как unicast-системы. Потому что там нет broadcast. Юрисдикционные машины. Какой нарратив сейчас в блокчейне? Мы построили классную юрисдикционную машину, которую все реплицируют. Так давайте на этом остановимся, вот её поподробнее пытаться расширять. Есть несколько основных веток, как её пытаются расширять. Мы сейчас отбросим payment-каналы Lightning и Bitcoin Way и сразу идём в Ethereum. Они пытаются создать роллапы, они пытаются создать вторые такие же юрисдикционные машины, которые блобами сохраняют историю в первую машину, но сохраняют ту же семантику. У тебя также есть общий глобальный стейт, и это сразу ставит крест на масштабирование, потому что как только появляется глобальный стейт, кто-то должен за тобой либо перепроверять, как в случае оптимистичных роллапов, либо как минимум хранить всю историю на случай, что ты пропадёшь, в случае ZK-роллапов. Обе эти ветки мертворождённые в плане data availability. Это никак не решить вообще. И третий способ...

(00:19:48) Сергей Тихомиров: Мы отбросим Lightning и Bitcoin — это как раз как будто Lightning отвечает на эту претензию, что там-то как раз стейт сконцентрирован между участниками и нет никакого глобального...

(00:19:56) Егор Хомяков: Мы их отбросим не потому, что не хотим про них говорить, а потому что я хотел сконцентрироваться на тех, кто пытается расширить broadcast. Lightning можно назвать родоначальником XLN: мы складываем Lightning с банками, мерджим их, и грубо говоря получается XLN. Банки, как мы уже выяснили, — единственная система наравне с интернетом, которая реально может поддерживать миллиард транзакций в секунду, тут безальтернативно. Lightning теоретически может, но по факту не поддерживает нисколько: они упёрлись в стену inbound liquidity. Договорю про broadcast. Роллапы у Ethereum — их точка масштабирования broadcast. Чем был успех Ethereum? Lego DeFi — общая EVM-среда, куда ты просто деплоишь контракты, и они начинают дружить друг с другом. Это очень круто, с 2017 по 2020 год работало красиво, всех устраивало. Потом пришёл реально компетентный контингент пользователей, которые начали это активно использовать. Транзакционные комиссии выросли, и все начали искать решение. Практически сразу отказались от state-каналов, потому что на тот момент казалось — и я так думал — что невозможно всю эту красоту Lego DeFi уложить в билатеральные взаимоотношения. Сейчас я заявляю, что это возможно и даже лучше, чем в старом Lego DeFi. Обсудим позже. Поэтому они жёстко сконцентрировались: нам надо больше того же. Мы хотим делать то же самое, но как-нибудь замасштабироваться. Так появилась идея роллапов.

(00:21:23) Егор Хомяков: Перед этим была Plasma, но от Plasma отказались, потому что у неё не было EVM-generality. Про это есть отдельный пост у Кевина. Цель была: нам нужно то же самое, которое также проигрывает legacy EVM, и хотя бы временно чуть-чуть масштабируется. Потом что-то придумаем. Третья ветка — я называю их big blockers, и в целом их все так называют. Это Solana и другого рода чейны: давайте вообще откажемся от любого ограничения, пусть у нод будет требование в 1 терабайт памяти. У Solana, если что, чтобы запустить ноду, даже последней Mac Studio не хватит — у меня она просто не влезает.

(00:21:53) Сергей Тихомиров: В целом я согласен с тем, что ты говоришь, и вижу ограничения, которые у всех этих архитектур есть. Мне кажется интересно и то, что ты думаешь по этому поводу: если мы хотим принести Money Lego, как в DeFi, для меня это неразрывно связано с тем, что есть некий центральный канонический стейт смарт-контракта, который разные пользователи пытаются изменить. Когда у нас Lightning, у меня канал с тобой, канал с Иваном, мы друг другу платим — и эти два канала в общем случае совершенно независимы. Но если у нас DEX, мы как раз хотим сделать трейд на DEX и конкурируем друг с другом за лучшую цену. Это фундаментально приближает нас к архитектуре, где есть центральная точка, в которую разные пользователи посылают свои транзакции.

(00:22:55) Егор Хомяков: Да, на первый взгляд кажется контринтуитивно, что в account-системах, в networks невозможно создать такой же Lego DeFi. На самом деле достаточно посмотреть шире: криптоиндустрия часто исключает из сравнения CeFi, DeFi и TradFi — традиционные финансы, которые, если что, до сих пор составляют 99,9% экономики. Там как раз всё работает на аккаунтах, один в один как в Lightning, только с другим обрамлением. В традиционных финансах можно сделать финансовое взаимодействие любой сложности: страховки, перестраховки, свопы, фьючерсы, что угодно. Там это покрыто не юрисдикционной машиной в коде, а английским языком, языком обычных контрактов на бумаге, и исполняется в суде людьми, которые эти контракты потом читают. Исполняется крайне плохо, но как-то работает. Наша задача — увидеть эти взаимодействия и перепрограммировать их в логику account-машины. Это возможно. Сейчас расскажу.

(00:23:52) Егор Хомяков: Казалось на сто процентов, что Lego DeFi возможен только если сохраняешь shared state, глобальное состояние, в котором все дружат друг с другом. Достаточно посмотреть шире и увидеть: цель не сохранить Lego DeFi, а дать людям такие юз-кейсы, конечный механизм использования. К чему сводится твой своп в Uniswap? В чём задача пользователя? Пользоваться AMM он не хочет — у юзера нет такой задачи. Он хочет сменить аллокацию в одном токене на аллокацию в другом без риска. В account-машине можно сделать то же самое. Только ты торгуешь не с… Я это вообще называю суррогатом. AMM — временный суррогат, который создали, чтобы воссоздать то, что замечательно работало на Hub & Spoke и до сих пор работает через брокеров. Твоими посредниками, контрагентами становится не конкретный брокер, а все сразу — сам алгоритм внутри смарт-контракта. Это безумно дорого, но даёт те гарантии, которые…

(00:25:00) Сергей Тихомиров: Хорошо. Ради этого всё и затевалось: мы заплатим цену в сложности, в комиссиях и так далее, но избежим центрального посредника, который может забанить тебя за одну секунду.

(00:25:10) Егор Хомяков: А он может забанить по какой причине? Потому что у тебя нет account-proofs? Потому что ваш механизм взаимодействия не подразумевает paper trail. XLN — это как раз создание такого механизма. По сути добавляются три системы защиты. Мы берём старую традиционную финансовую систему и называем её FCUAN — на главной странице есть расшифровка. Суть: full credit unprovable account network. Она полнокредитная, недоказуемая, это сеть аккаунтов. Так мы называем практически всё финансовое взаимодействие в мире. Твоё взаимодействие с банком — FCUAN, с Binance, Coinbase — хотя это крипта и другая юрисдикционная машина, но тоже FCUAN: число в их базе данных, которое могут в любой момент стереть, и у тебя нет доказательств. Ключевой апгрейд XLN: поверх FCUAN добавляем FRPAP.

(00:25:57) Егор Хомяков: Это Full Reserve Provable Account Primitives. Как раз Lightning, Raiden и остальные state-каналы пытались это создать. Мы снова не используем каналы — опять называем это аккаунтом, потому что для взаимодействия между двумя сущностями слово уже есть. Это аккаунт, двухсторонний аккаунт между двумя сущностями. Слово «канал» изобретать не нужно было. Их проблема в том, что это даже нельзя назвать сетью — я не использую слово network. В конце называю это primitives. Когда пытаешься построить на полнорезервных аккаунтах, сеть просто не складывается. Как Lego, у которого с двух сторон шипики: оно не соединяется с другими Lego. Чтобы пользователю получить ликвидность, кто-то должен залочить её в твою сторону. Я говорю об этом с 2017 года: не работает. Объективно ничто из этого не заработало. Все остальные канальные проекты умерли, кроме Lightning, который как-то ещё делает вид, что существует, — за счёт энтузиастов. Когда несколько десятков энтузиастов друг другу залочили ликвидность в свою сторону и могут послать 10–100 баксов, для них это уже победа. Я не считаю это финалом истории и тем, как должны работать канальные системы. Это надо масштабировать на всё человечество. Я верю в каналы больше, чем любой Lightning-энтузиаст, на самом деле.

(00:27:04) Сергей Тихомиров: Вопрос в том, что называть каналами, но если мы от этого термина уходим…

(00:27:14) Егор Хомяков: Это просто полнорезервный аккаунт — аккаунт с полным резервированием в юрисдикционной машине. Есть сумма, залоченная в escrow между двумя сущностями. Это классическое описание канала.

(00:27:20) Сергей Тихомиров: Окей. Что я пока понял на этом этапе? Есть или были две системы, в каком-то смысле противоположные. Одна — Lightning: чтобы присоединиться к off-chain взаимодействиям без доверия, нужно пронести капитал, запереть его или добиться, чтобы к тебе заперли капитал — полностью обеспечить все будущие взаимодействия в рамках протокола. Это дорого и неудобно. На другом конце спектра традиционный финансовый мир, который держится более-менее на честном слове.

(00:27:52) Егор Хомяков: На доверии, да.

(00:27:54) Сергей Тихомиров: Плюс суды и юрисдикция — с тобой не совсем соглашусь, когда говоришь, что в банковском аккаунте просто циферки без доказательств. С точки зрения криптографии они циферки, но они обеспечены легальной системой и судами в этой стране. Это не совсем пустое слово. Я понимаю, в чём…

(00:28:08) Егор Хомяков: Оно и не полное. Где-то посередине, как повезёт — зависит ещё от страны. В Намибии банк реально может удалить аккаунт, а что ты сделаешь? В Англии процесс посложнее. Суть: мы как технологи должны понимать, что с первого дня взаимодействия с банком можно включить screen recording на телефоне и записывать всю HTTPS-сессию — это не поможет в суде доказать, что в эту секунду у тебя были деньги. T+1, банк говорит, что ты всё вывел. Это не paper trail, нет протокола, который гарантирует, что деньги всегда по нажатию кнопки на твоём девайсе доступны. Первое, что XLN должен достигнуть, — чтобы любое взаимодействие с контрагентом шло через этот paper trail и было доказуемо. По сути микроблокчейн на двух участников: мы создаём с тобой state-машину с билатеральным консенсусом. Любое слово — не только денежные переводы; можно представить телеграм-чат. Я пишу «Привет», у тебя подписанное сообщение, account-frame, account-block со словом «Привет». Ты можешь вырезать с седьмого по десятое сообщение и вставить на публичный форум — там просто мои ключи. Это очевидно. Как минимум лучше, чем скриншот.

(00:29:20) Сергей Тихомиров: Мне кажется, теперь я понял разницу. Снова немного с Lightning-овой позиции. Чем обеспечивается безопасность — тот факт, что можно оспорить неправильное состояние? Тем, что все состояния подписаны обоими участниками. Алиса и Боб, чтобы перейти в следующее состояние: Алиса говорит, что хочет послать что-то, Боб подписывает этот state transition. Тогда блокчейну можно принести переход, подписанный обоими. То, что ты говоришь — как я понимаю, одна из ключевых вещей в XLN: независимо от того, насколько финансово взаимодействия обеспечены кредитом или collateral…

(00:30:10) Егор Хомяков: …или суммой их — там нет такого, что только кредит или только collateral, это любое количество.

(00:30:12) Сергей Тихомиров: Независимо от доли, каждый переход подписан обоими участниками, и оба заверяют его таким способом.

(00:30:13) Егор Хомяков: Сто процентов. Именно так.

(00:30:15) Сергей Тихомиров: Окей. Это понятно, это хорошо.

(00:30:16) Егор Хомяков: Я даже расскажу, как я пришёл к аккаунт-машине. У меня был JavaScript-код, в котором state-transitions уходили без какой-либо упорядоченности. Они могли послать их друг другу одновременно, и сразу возникает конфликт: оба хотят послать transition. У вас есть начальное состояние, и рано или поздно вы приходите к идее реплицируемой стейт-машины. Мы начали с общего примитива и создали юрисдикционную машину. Теперь делаем примитив аккаунт-машины — по сути билатеральный блокчейн. Раньше так никто не делал. Суть в том, что есть состояние, не обязательно связанное с деньгами прямо сейчас — некий Merkle tree. Чтобы его изменить, у аккаунт-машины есть mempool: ты накидываешь туда transitions. Если машина в состоянии ready и готова отправить, создаётся фрейм с просьбой «подпиши мне». Ты шлёшь его второму участнику по сети. Как только он его видит, для него это уже финально — моментальная финальность. Как только он подписывает со своей стороны, у него две подписи, и он знает, что может пойти в юрисдикционную машину и затребовать то, что ему только что пообещали. В обратную сторону работает так же.

(00:31:20) Егор Хомяков: По сути это неблокируемый дуплекс — так называют протоколы, где стороны могут одновременно слать друг другу transitions. Безопасность в том, что в любую секунду, в любую микросекунду у каждого есть последний account-proof, подписанный вторым участником, с которым можно пойти в юрисдикционную машину. Та потом запускает dispute timeout, например 24 часа, и смотрит nonce. Один приносит account proof с nonce 17, другой — с nonce 18: второй побеждает, и, возможно, penalty тому, кто принёс более старую nonce.

(00:31:50) Егор Хомяков: То же самое, что в Lightning: там это называют commitment-транзакциями. Отличие в том, что commitment-транзакция — это уже готовая транзакция, которая тратит старый account-output, UTXO. Это неудобно, потому что ты вынужден работать с сырыми данными, которые пойдут в саму юрисдикционную машину — Bitcoin в данном случае. В Ethereum можно сделать красивее: например, батчинг. Хаб может послать не один account-proof за одну транзакцию, а тысячу. Он может одновременно начать dispute с тысячи контрагентов.

(00:32:20) Сергей Тихомиров: Если смотреть чуть более high-level с точки зрения приложения, где это полезно, у меня две картины. Одна унаследована от Lightning. Если приложить XLN к юз-кейсу, где люди просто хотят офф-чейн обмениваться платежами и гонять монетки между собой, мне легко представить аккаунт или, в терминах Lightning, канал с состоянием. Я говорю: хочу перевести в другое состояние. Ты отвечаешь «окей» и подписываешь. Следующее состояние со следующим nonce — и так дальше, здесь я понимаю, как это работает. Где я понимаю хуже — если приложить это к юз-кейсу, где две стороны неравнозначны: одна биржа или финансовый сервис, другая — пользователь. Как обеспечить, если я пользователь, а ты сервис: я предлагаю перевести аккаунт в следующее состояние, а ты не хочешь? Ты можешь меня зацензурировать, пропустить другую транзакцию впереди моей и так извлечь MEV. Как-то адресуются эти вопросы? Или предполагается, что если одна сторона говорит «хочу перевести в это состояние», вторая всегда отвечает «окей, согласен»?

(00:33:36) Егор Хомяков: Во-первых, так не бывает, что вторая сторона всегда автоматически соглашается. Конечно, можно допустить, что она просто ушла в оффлайн — не обязательно даже «не согласна», это византийское поведение, абсолютно предсказуемое и ожидаемое. Для этого у тебя есть последний account-proof. По сути у вас аккаунт-машина в состоянии консенсуса: ты предлагаешь новый блок, новый фрейм. Я предпочитаю «фрейм», потому что фрейм ассоциируется с FPS, а аккаунты реально работают на такой скорости — десять фреймов в секунду при взаимодействии двух хабов, например. Когда один предлагает другому, а второй резко ушёл в оффлайн, можно подождать десять минут — может, появится и подпишет. Либо отправить последний account proof в юрисдикционную машину и получить токены, которые там были на последний момент. Когда ты пытаешься применить транзакции или сделать платёж, это сдвижение дельты в его сторону. Если левый хочет послать правому, он должен сдвинуть дельту на себя, увеличивая аллокацию второго участника.

(00:34:40) Егор Хомяков: По сути это предложение: согласен ли ты с этим изменением? У второго участника в аккаунт-машине тот же код, что и у первого — TypeScript, который выполняет этот state transition. Если transition успешно выполняется, у него нет причин отказываться. Но если он всё-таки хочет отказаться — окей.

(00:34:55) Сергей Тихомиров: Давай разберём подробнее анатомию одного отдельного аккаунта. Ты упоминал дельту. Если у нас Алиса и Боб хотят в рамках XLN что-то сделать — что происходит?

(00:35:24) Егор Хомяков: Важно сразу отказаться от Алисы и Боба: в реальной сети их нет. Mesh-сети между конечными пользователями крайне маловероятны. Скорее единственное взаимодействие — две корпорации, например. Для этого существуют хабы.

(00:35:32) Сергей Тихомиров: Алиса и Боб здесь просто placeholder names.

(00:35:33) Егор Хомяков: Окей, придираюсь. Алиса и хаб. Когда Алиса открывает хабу и хочет принести collateral — как идёт запрос? Первым делом Алиса делает транзакцию в свою локальную стейт-машину. Появляется третья машина, тоже в виде реплицированной стейт-машины, но с одной нодой — runtime-машина. По сути мы оборачиваем весь кошелёк в одну стейт-машину: скармливаем инпуты, и она создаёт фреймы буквально каждые 10–100 миллисекунд, постоянно. Это дискретная симуляция системы.

(00:36:06) Сергей Тихомиров: Можно перебить на секунду? Правильно ли, что действующие лица — типы сущностей — это юрисдикция наверху, entity-машина — другими словами хаб или сервис, а runtime-машина — это…

(00:36:22) Егор Хомяков: И конечные пользователи. Конечные пользователи — тоже entity-машины.

(00:36:28) Сергей Тихомиров: Entity и runtime — разные сущности?

(00:36:30) Егор Хомяков: Разные вещи, да. Runtime — обёртка вокруг всего, что происходит в кошельке. Симуляция, можно сказать, матрица. Entity, account, юрисдикция — уровни. Runtime — обёртка для симуляции.

(00:36:44) Сергей Тихомиров: Про runtime забыли. Но аккаунт, как я понял из того, что ты говорил раньше, — не сущность как таковая, а взаимодействие между двумя сущностями.

(00:36:50) Егор Хомяков: Верно. Это стейт-машина, которая живёт внутри entity-машины — Merkle tree. Как контракт живёт в стейте Ethereum. Подуровень. Все entity-машины живут в runtime.

(00:37:02) Сергей Тихомиров: Правильно ли сказать, что аккаунт — абстракция, которую совместно поддерживают две entity-машины?

(00:37:12) Егор Хомяков: Да. Два квадратика, у каждого маленькие квадратики, соединённые линией. Хочешь послать сообщение — как cans, по которым можно что-то передать, соединённые линией. Вот это и есть аккаунт-машина. Но она полностью существует.

(00:37:26) Сергей Тихомиров: Я пытаюсь провести границу между теоретической абстракцией и конкретным куском кода на компьютере. Юрисдикция — кусок кода, entity — кусок кода, а аккаунт — абстракция, которую совместно поддерживают…

(00:37:45) Егор Хомяков: Это тоже кусок кода — account TS. Весь запрос идёт по иерархии, начиная с runtime. Runtime вызывает entity-машину. Entity-машина — просто набор функций, по большому счёту map-reduce. Всегда входящая точка любого взаимодействия в сети — runtime. Напрямую вызвать entity или аккаунт нельзя. Runtime внутри передаёт по цепочке, вызывает Apply Entity Input — применить input к entity-машине. Всё в функциональном стиле, без классов, специально для упрощения. Внутри entity вызывает аккаунт-машину, пытается добавить в mempool и дальше создаёт фрейм, если аккаунт-машина в состоянии ready. Если не готова отправлять, mempool пополняется и ждёт confirmation от второго участника, от второй entity. Два больших квадратика — две entity. Маленькие квадратики внутри — аккаунт-машины, через которые они общаются. По-другому, по сути, и сделать было нельзя.

(00:38:42) Сергей Тихомиров: Я пытаюсь понять, насколько уместна параллель между аккаунтом в XLN и каналом в Lightning. Канал — это абстракция, которую совместно поддерживают два узла. На машинах участников работает какой-то код, но нельзя сказать, что канал локализован внутри одного компьютера. Это абстракция, поддерживаемая синхронизируемым стейтом между двумя участниками.

(00:39:06) Егор Хомяков: Тогда мне нужно понять, что ты имеешь в виду под абстракцией. В конкретном Lightning Daemon, LND, есть конкретный кусок кода, который работает с конкретным стейтом и сохраняет его куда-то. Когда я слышу слово «абстракция», я думаю о чем-то совсем другом.

(00:39:19) Сергей Тихомиров: У нас есть Алиса и хаб. Алиса хочет подключиться к хабу и сконструировать аккаунт.

(00:39:26) Егор Хомяков: По сути создать genesis этой account-машины. Для этого начинается иерархический танец. Алиса делает запрос в свою runtime-машину, та внутри обращается к single-signer entity — сейчас это простой кошелёк. Можно делать и multisigner entity, но это уже сильно сложнее. Транзакция попадает в signer-машину Алисы, в entity-машину. Она single-signer, ей ничего не нужно ждать: сразу создаётся блок, внутри которого делается genesis account-машины с хабом. По цепочке назад через outbox или просто return функции message возвращается в runtime-машину и по WebSocket попадает на сервер хаба, в его runtime-машину. Оттуда он залетает в entity-машину хаба, внутри его runtime-машины: «У меня нет account-машины с Алисой». Я хаб, у меня настроено открывать всем подряд или открывать по KYC — это не принципиально. Если все conditions соблюдены, автоматически происходит такой же симметричный genesis уже в runtime entity, в этом стэке у хаба. В итоге у них две account-машины с одинаковым хэшем, состояние полностью симметричное. Что такое account-машина? Это микро-Ethereum блокчейн со стейтом. Стейт — по сути account-proof из нескольких компонентов: header, левый и правый участник (Алиса и хаб в данном случае), последняя nonce (начинается с нуля) и конфиги вроде того, кто какой delay ставит при dispute. Основное — Delta List: список дельт для каждого токена. Они начинают с простого пустого массива, но могут наполнить его account-транзакциями. Например, добавить USDT, USDC и Wrapped Ethereum. По умолчанию off-delta равна нулю.

(00:41:16) Сергей Тихомиров: Нам нужны определения. Что такое дельта, что такое off-delta, что такое on-delta.

(00:41:32) Егор Хомяков: Определений немного, буквально одно. Дельта — это подписанный integer между двумя участниками: может быть ноль, минус сто или плюс сто. Net balance — сальдо, одно число, которое важно знать для данного токена между левым и правым участником. Его можно двигать в любую сторону, как счёты, как в Lightning, только там другой механизм. Есть unspent transaction output, например один биткоин, и вы делите аллокацию: половину себе, половину ему, одну десятую себе, девять десятых ему. Но нельзя отдать целый биткоин ему и ещё немного в долг. Механизм не поддерживает сдвиг дельты в минус. Я говорю, что не нужно держать два числа — всё сводится к одному net balance, который может быть отрицательным или положительным.

(00:42:16) Сергей Тихомиров: Мне кажется, здесь две разные оси. Ты говоришь, что в Lightning сложно, потому что мы делим в пропорции, а delta — одно число. Но это, по сути, одно и то же: мы заперли один биткоин в канал, можем сказать «четверть мне, три четверти тебе» или «delta равна 25%» — та же абстракция. Добавление 25 к этому — ортогональный аспект. И ещё мы можем разрешить delta выходить за нулевой порог.

(00:42:43) Егор Хомяков: Согласен, это другое. Я говорю, что удобнее, когда вместо двух чисел при конкретном on-chain числе — один биткоин — ты указываешь, как делишь, одно число. Как в банкинге: баланс 100, 0 или минус 100. Зачем хранить два числа, которые всё равно связаны друг с другом? В Raiden сделано ещё хуже: там четыре числа — кто сколько задепозитил, кто сколько кому послал. Когда я на это смотрел — невозможно пользоваться только off-chain дельтой. Как только ты депозитишь collateral в юрисдикционной машине, увеличиваешь со своей стороны «зелёненькое», дельта резко уезжает: зелёное добавилось, а ты хотел добавить не с левой стороны, а с правой. Эту дельту надо подвинуть во время юрисдикционного депозита, не делая off-chain-транзакций. Поэтому я разделил дельту на два числа: on-delta и off-delta. On-delta — то, что хранится в юрисдикции, подписанный integer, может быть отрицательным и положительным. Off-delta — то, чем вы реально обмениваетесь в off-chain-транзакциях. В зависимости от того, как вы используете XLN, это может быть система off-chain-переводов или on-chain-ребаланс. Вы сдвигаете ту дельту, которая в данный момент вас интересует.

(00:43:56) Сергей Тихомиров: On-delta и off-delta. Имеет ли дихотомия on-off отношение к вопросу, кредитное это взаимоотношение или backed by collateral? Это одно и то же или ортогональные вещи?

(00:44:17) Егор Хомяков: Ортогональные, не связанные. Дельте всё равно, где она сейчас — поверх collateral или поверх кредита. Это другой уровень абстракции. Дельта может быть 100, и неважно, 50 у тебя collateral или 0 — она просто 100. В момент dispute происходит разрезание collateral. Ты предоставляешь account-proof с off-delta, юрисдикционная машина знает набор on-delta и складывает их. Для USDT складываются on-delta и off-delta из proof — получается, например, 100 минус 50, то есть 50. Collateral в этот момент был, скажем, 70. Суммарная дельта 50 при collateral 70 значит: 50 collateral идёт одному участнику, как колбаса режется, 20 — правому. Это знакомый кейс. Интереснее, когда суммарная дельта выходит за пределы collateral. Тогда весь collateral отдаётся участнику с той стороны, где дельта. Визуально понятно. Части, которой не хватило, помогает механизм вакуума ликвидности — он прописан в Solidity. У каждой entity в юрисдикционной машине есть резервный счёт, standalone-аккаунт, с которого можно затребовать деньги, как fractional reserve. Если денег достаточно, они автоматически переходят второму участнику. Если нет — на недостающую сумму создаётся объект долга на участнике, который должен. Звучит просто, и так реализовано — предсказуемо, без сложной математики.

(00:45:45) Сергей Тихомиров: Для меня в off-chain-системах в широком смысле самый интересный вопрос — что происходит, если у нас разные представления о том, кто кому что должен на первом слое, и как разрешаются конфликты. Правильно ли я понимаю, что конфликты разрешает юрисдикционная машина? Здесь параллель с Lightning, как при оспаривании закрытия канала. Но поскольку semantic XLN разрешает кредитные взаимодействия, а не только полностью обеспеченные, если мой долг тебе превышает мой collateral, юрисдикционная машина автоматически взимает его с счёта, который я заранее положил при регистрации, и возвращает долги. А если не хватает, чтобы покрыть все долги, тогда...

(00:46:26) Егор Хомяков: Тогда в Solidity создаётся объект долга — new debt object в storage, который висит на твоей сущности, на твоём identity. Если ты хаб — а в основном долги будут затребованы с хабов — при rebalance ты с collateral других участников высасываешь деньги на резервный счёт, а когда кому-то подкладываешь, с резервного: это collateral to reserve и reserve to collateral. В Solidity функции так и названы. Каждый раз, когда ты пытаешься уйти с резервного счёта, вызывается enforce debts на твой identity: циклом перебираются долги first in, first out, и все выплачиваются. Избежать оплаты долга невозможно, кроме полного коллапса, полного rug pull, когда ты исчез. Да, можно потерять деньги, если хаб, который тебе должен, полностью заскамился и больше не вернётся. Но Coinbase не может кинуть тебя на 10 тысяч долларов и продолжить оперировать в этом ассете, в USDT: как только он сделает rebalance кому-то ещё, сначала заплатит долги, которые на нём висят.

(00:47:30) Сергей Тихомиров: Извини, а если американские санкции? Coinbase может кинуть часть пользователей и продолжить обслуживать другую часть. Ему что-то помешает сделать это в архитектуре XLN?

(00:47:41) Егор Хомяков: Как раз не сможет.

(00:47:44) Сергей Тихомиров: В моей картине мира децентрализованные системы изначально задумывались, чтобы избежать ситуации, когда централизованный посредник может по каким-то причинам в широком смысле цензурировать пользователей: заморозить счета по паспорту или по другому признаку. Я пытаюсь понять, насколько в архитектуре XLN этот concern адресуется. Или это вообще не про то?

(00:48:06) Егор Хомяков: Это основа. Proof-ы — первый уровень защиты поверх этой FCUAN, полнокредитной системы. Мы формализовали взаимодействие любых двух сущностей. В процессе у вас всегда есть account-proof — доказательство, с которым ты идёшь в юрисдикционную машину. Она работает по алгоритму, ей всё равно, у кого какие санкции, и гарантированно повесит объект долга, если у Coinbase нет резерва. С большой вероятностью там будут, например, 10 миллионов, и можно сразу получить деньги в ту же секунду, когда dispute финализировался. Если ноль — копаешь глубже и вешаешь на него долг. На следующий день он делает rebalance collateral в том же токене, в USDT — твой долг гарантированно покроется. Любая операция с резервом: первая строка — enforced debts, гарантированная выплата всех долгов. По-английски это, по-моему, bank levy: на должника вешают блок, как на машину — не уедешь, пока не закроешь. Здесь то же самое алгоритмически гарантируется смарт-контрактом.

(00:49:09) Сергей Тихомиров: Немного издалека. При подготовке к выпуску я пользовался AI, разговаривал с ним, и он подсказал такой ход мысли — интересно, что ты скажешь. В традиционной банковской системе есть механизм взыскания с обанкротившихся сущностей, но вкладчикам прописано правило: либо страхование вкладов, либо если лимиты превышены, остаток возвращается в пропорции. Обычно не «первые получили всё, последние ничего», а все получили, скажем, 60% — haircut, как на Кипре. В XLN, поправь, если неправильно, полную выплату по долгам получают те, кто первыми обратился: FIFO, first in, first out. Кто первым прибежал — получил полностью, кто опоздал — ничего. Панчлайн: это стимулирует bank run. Если у entity появляются признаки нестабильности, у пользователей incentive как можно быстрее забирать деньги: если опоздаешь — ничего не получишь. Если бы они знали, что в худшем случае получат хотя бы 60%, может, не паниковали бы, bank run не случился бы, entity не обанкротилась. Как ты на это смотришь? Это разумная критика?

(00:50:32) Егор Хомяков: Да, я долго это ресёрчил, и именно эта часть контракта в Solidity плотно покрыта комментариями по этому вопросу. Почему не haircut, а FIFO? Потому что в традиционных финансах всё работает по другим законам. Здесь можно сделать Sybil-атаку: создать тысячу аккаунтов в конце очереди, когда реальные вкладчики уже начали затребовать, и каждому «должен» по миллиону. Haircut сразу перетекает в их сторону — тебе не достаётся ничего. Хотя они в хвосте, суммарный volume, который ты им «должен», становится в сто раз больше, чем всё, что было до.

(00:51:10) Сергей Тихомиров: Условно, если я банк, который хочет заскамить всех и убежать с деньгами, вместо того чтобы отдавать всем 60%, я создаю фейковых юзеров, делаю вид, что должен им триллион, им честно возвращаю — а это мои же entity.

(00:51:25) Егор Хомяков: Да.

(00:51:27) Сергей Тихомиров: Окей, fair enough.

(00:51:28) Егор Хомяков: FIFO — единственный алгоритмически честный способ. Это раз. И два: если сильно надо, можно переписать код. Это не жёсткие стандарты XLN, всё это для white label юрисдикции. Например, какая-то страна хочет задеплоить, но ей не нравится этот механизм — можно переписать. Это не жёсткий стандарт. Ты поднял тему АСВ. Я могу очень долго и качественно хейтить агентство страхования вкладов. АСВ — типичная российская история, но, как я понимаю, принцип страхования вкладов универсален. Везде одинаковый. Deposit insurance scheme — так это называется, я долго это ресёрчил. По сути, XLN во многом является решением этих фундаментальных банковских проблем. Их три. Страхование депозитов. Проблема Diamond-Dybvig, bank run, которую ты выше поднял: рассинхронизация ликвидности, когда с одной стороны резко выдергивают вкладчиков, а с другой ты не можешь так же резко выдергивать активы. И Coase economics — нужно понизить транзакционные издержки, чтобы всё было быстрее и экономика росла быстрее, потому что сейчас слишком большие комиссии. Про страхование вкладов люди, которые занимаются финансами профессионально, всё это хейтят, потому что там две проблемы. Во-первых, они morally hazardous: круговая порука, где все коммерческие банки, покрытые страховкой, должны вкидываться премиями раз в квартал. В США они переводят несколько миллиардов долларов каждые три месяца в FDIC, и фонд растёт. Казалось бы, ради большой цели можно. Но знаете, сколько процентов покрывает этот фонд от реального объёма банковской системы? Меньше 1%.

(00:53:00) Сергей Тихомиров: Цель же не в том, чтобы покрыть большую часть по ценности. Цель в том, чтобы защитить мелких вкладчиков. В США 300 миллионов избирателей, у которых лежит по несколько тысяч или несколько десятков тысяч долларов, чтобы они спали спокойно и знали, что если что, им всё вернётся.

(00:53:15) Егор Хомяков: Таким образом ты можешь защитить только банк за пределами топ-20. Как только в топ-20 — просто недостаточно денег. Вот сумма, которую надо защитить. Вот сколько у тебя есть. Это механизм успокаивания населения.

(00:53:28) Сергей Тихомиров: Получается, такого рода принудительная страховка приводит к ситуации, когда топовые банки too big to fail, и если кризис, их бэйлаутят за средства тех же налогоплательщиков, которых мы собираемся защищать.

(00:53:40) Егор Хомяков: Это раз. А два — деньги у страховки откуда берутся? Тоже от вкладчиков. И так, и так система высасывает из всей структуры за счёт премий. Просто они не прямые: за тебя платит банк и перекладывает на тебя эти комиссии.

(00:54:00) Сергей Тихомиров: Конечно. Это размазывание риска более плавно, чтобы не было резких движений.

(00:54:04) Егор Хомяков: Теперь важно взглянуть на полнорезервную часть каналов как на механизм «страховка депозитов 2.0». В традиционных финансах страховка депозитов — это shared котёл, в который все вкидывают по копеечке, чтобы потом попытаться покрыть. Но это и создаёт morally hazardous архитектуру: банки могут идти на более рискованное поведение, потому что они лицензированы и знают, что общий котёл покроет — либо из бюджета закроют дыру, либо возьмут в долг из будущих премий. Так было в 2008 году. Если убрать это из уравнения или снизить в разы, сделать опциональным, и одновременно добавить резервы, которые человек сам выбирает со своим хабом — collateral канала — то это уже ответственность. Рано или поздно люди научатся, что ты выбираешь, насколько хочешь быть collateralized: на 100%, на 80, на 50, на 20, на 0. Если выбираешь 20%, то во время кризиса, когда перед твоей хабовой сущностью происходит bank run, ты гарантированно получишь из collateral — по сути, это твоя личная страховка депозитов. Она залочена между тобой и хабом именно в этой ячейке юрисдикционной машины. Вместо «звёздочка-звёздочка равно для всех».

(00:55:17) Сергей Тихомиров: Я пытаюсь приложить это к какому-то общеприменимому юз-кейсу. Вот я работаю, хочу зарплату получать к тебе как к хабу или к банку. Говорю: хочу у тебя открыть аккаунт и получать деньги. В Lightning как раз здесь была проблема: нужно было уговорить тебя задепозитить ликвидность в мою сторону и держать её на случай, если мне что-то придёт. А я прихожу к тебе как service provider и говорю: открой мне счёт, буду получать зарплату на этом аккаунте. Дальше я могу сказать, что мне не нужно обеспечение, fully credit backed — мне окей. И это работает без всяких усилий со стороны страны. Или могу сказать: хочу 50% collateralized. Это будет означать, что на каждые 100 долларов, которые я получаю, 50 именно под меня зарезервированы лежат в твоём резерве. Или могу сказать 100 — тогда все 100 лежат в твоём резерве.

(00:56:11) Егор Хомяков: Да, но collateralization происходит потом. Сначала ты получаешь по кредитной линии, они накапливаются. И в фоне во время каждого пятиминутного rebalance — вся задача хаба каждые 5–10 минут делать rebalance, пройтись по всем своим аккаунт-машинам, своей entity-машине. Их может быть миллион, например. Такой map-reduce: посмотреть — тут договорились на 50% collateral, а на самом деле 10%, значит надо подложить. Или договорились на 20%, а сейчас большая collateralization, или он мне переслал — тут надо вытащить. Он создаёт batches, где у многих вытаскивает collateral, многим закладывает. Ты как работник говоришь хабу: хочу такую collateralization — это не значит, что гарантированно 100% времени у тебя будет именно такая collateralization. Это значит, что хаб делает best effort, чтобы её предоставить. Если он этого не делает, ты просто работаешь с другим хабом.

(00:57:00) Сергей Тихомиров: А для меня как пользователя эта операция transparent: я могу проверить, что действительно 50%. Хотя бы что ты делаешь best effort, как бы это ни было определено.

(00:57:10) Егор Хомяков: Конечно. Максимально прозрачно в кошельке. По сути, это будет один слайдер от нуля до 100%.

(00:57:15) Сергей Тихомиров: Слайдер — да. А откуда я как пользователь знаю, как ты rebalance'ишь мой аккаунт против каких-то других аккаунтов совершенно чужих людей?

(00:57:24) Егор Хомяков: К сожалению, это невозможно.

(00:57:30) Сергей Тихомиров: Ты можешь хотя бы следовать тому, что я тебя проинструктировал. Я хочу collateralization 50, ты говоришь: окей, будет 50, а на самом деле в фоне ничего нет. Как я об этом узнаю?

(00:57:37) Егор Хомяков: Во-первых, в кошельке всё-таки показано: есть стек из барчиков, один зелёный, другой красный, и ты видишь, что всё красное — значит всё в риске. Кошелёк говорит: динь-дон, ты должен уходить от этого хаба, потому что он тебя до сих пор не collateralized. Но если у тебя collateralization 40, а ты хотел 50%, ты никак не убедишься, что это лучшее, что он может, потому что не можешь залезть внутрь хаба и узнать.

(00:58:00) Сергей Тихомиров: Я не могу залезть внутрь хаба. Допустим, хочу 50% collateralization, а на практике внутри твоей системы она, я не знаю, 5 или 0. И это для меня неприемлемо. Как я узнаю… Сейчас переформулирую. Как пользователь может убедиться, что ты один и тот же collateral не переиспользуешь для разных пользователей? Один и тот же биткоин лежит, и ты говоришь: это collateral в твой канал, и в твой, и в твой. А потом, когда мы придём dispute и устроим bank run, выяснится, что…

(00:58:37) Егор Хомяков: Нет, конечно же. Ты постоянно слушаешь юрисдикционную машину, скачиваешь все events, связанные с твоей entity-машиной. Внутри entity-машины есть маленькая копия всего, что хранится в юрисдикционной машине. Ты всегда видишь, сколько реально там находится в collateral. Гарантированно.

(00:58:52) Сергей Тихомиров: Это shared state. Звучит как shared state.

(00:58:54) Егор Хомяков: Да. Кусок стейта, который связан именно с твоей сущностью — не всю юрисдикционную машину, а те аккаунты, которые вокруг тебя. Ты знаешь collateral. Кошелёк в любой момент может показать, насколько ты реально collateralized. Collateral всегда назначен какой-то конкретной сущности. Его нельзя зашерить на всех. Именно в этом его соль.

(00:59:13) Сергей Тихомиров: Почему это не то же самое, что проблемы data availability?

(00:59:16) Егор Хомяков: У data availability проблема в том, что у тебя нет данных. А здесь наоборот: у тебя есть все данные, которые нужны для выхода. Просто нет третьих лиц, на которых ты висишь.

(00:59:24) Сергей Тихомиров: Легко представить, как криптографически доказать, что есть какой-то collateral и ты его закоммитил к моему аккаунту. Но как мне доказать, что ты не закоммитил его ещё к тысяче других аккаунтов?

(00:59:36) Егор Хомяков: Потому что это хранится в смарт-контракте, в storage. Есть mapping collaterals: слева юзер, справа юзер, какой-то токен, такая-то сумма.

(00:59:47) Егор Хомяков: Например, 1000 USDT. Невозможно закоммитить на два аккаунта сразу: они залочены в one-to-one relationship. Это не общий пул ликвидности. Резерв как раз и есть общий пул ликвидности, потому что он ни на кого не закоммичен, он disposable. Хаб может в любую секунду отправить его на третий адрес, и ничто его не ограничит. Любое ограничение будет бессмысленным. Недельный delay в духе bonding тоже сделает схему бессмысленной. Из-за механизма я могу сказать, что должен этот резерв другим Sybil-сущностям, и они вытянут его так или иначе. Поэтому важно: резерв — это hot wallet, на него можно посматривать, но нельзя доверять, что он всегда там будет. Collateral же гарантированно залочен. Его нельзя достать без подписи обоих участников.

(01:00:32) Сергей Тихомиров: То есть collateral привязан к конкретному аккаунту. Это не часть какого-то общего мешка.

(01:00:37) Егор Хомяков: Конечно.

(01:00:43) Сергей Тихомиров: И я могу это проверить, посмотрев соответствующий смарт-контракт. Значит, мне всё-таки нужно трекать.

(01:00:44) Егор Хомяков: На Etherscan можно посмотреть.

(01:00:45) Сергей Тихомиров: Или где-то получить доступ к storage аккаунта и убедиться, что моя доля там примерно такая, как я хотел. Ещё одна вещь, которую хотел обсудить: мультихоп-платежи. Одна из вещей, которые я люблю в Lightning, хотя понимаю, что это дорого и, возможно, непрактично, но кажется элегантным, — механизм атомарных мультихоп-платежей. Если одно число раскрыто, все хопы прошли. Если не раскрыто, ни один не прошёл. Есть ли аналог этого механизма в XLN и как работают платежи через несколько аккаунтов, если я правильно употребляю термин?

(01:01:33) Егор Хомяков: Да, мы как раз вчера в чате вспоминали AMP. Создать это несложно, довольно простая функция, но я считаю это gimmick. Она не решает никакой реальной проблемы. Крайне редко в жизни, когда надо что-то оплатить, тебе в упор хватало одного банковского счёта, и ты чуть-чуть добавил с другого. В конце концов ты мог перекинуть деньги с одного счёта на свой основной и отправить полную сумму.

(01:01:58) Сергей Тихомиров: Мне кажется, мы сейчас говорим о разных вещах. Я скорее про историю, когда у меня счёт в Сбере, а у тебя в Тинькове. Я хочу отправить тебе перевод по системе быстрых платежей. Сбер и Тинькофф как-то договорились между собой, чтобы это сработало, правильно?

(01:02:13) Егор Хомяков: Ты говоришь про multihop. Не про Atomic Multipath.

(01:02:18) Сергей Тихомиров: А, не про Atomic Multipath, хотя и про это тоже можно поговорить. Я имел в виду просто раз, два, три, четыре хопа.

(01:02:20) Егор Хомяков: Multihop, конечно, без него никуда, это основа. Состояние как Lego, по сути шардируется: аккаунт — это микрошарды, самая последняя форма шардов. Есть шарды на трёх и более участников, как в Canton, в Dot, в TON, в Near и в других шардинг-чейнах. Каналы — финальная форма, к которой шардинг должен прийти, потому что они двусторонние. Нет ничего эффективнее сетки двусторонних отношений. Вся соль в том, что ты соединяешь эти независимые микрочейны через hashlock'и, hash-time-lock-контракты. Это бит информации: был ли раскрыт секрет к какому-то хэшу в юрисдикционной машине до какого-то момента. За счёт этого маленького бита можно передавать любую информацию из одной аккаунт-машины в другую, потому что биты можно наращивать друг за другом. Ещё круче: биты можно строить лесенкой. Они сворачиваются, и можно передать хоть 32 байта из одной аккаунт-машины в другую через, скажем, восемь hashlock'ов.

(01:03:25) Сергей Тихомиров: По сути, тот же механизм, что в классическом Lightning. Есть секретное число, которое, видимо, должен сгенерировать получатель. Он его раскрывает… Вот здесь я не до конца понял. Ты говоришь «раскрыто число в юрисдикционной машине». В Lightning же не обязательно раскрывать этот секрет на блокчейне. Он раскрывается непосредственно партнёру по каналу.

(01:03:53) Егор Хомяков: В хорошем случае. В плохом ты идёшь и форсируешь юрисдикционную машину. Механизм аналогичный. В хорошем случае, конечно, стопроцентно. В плохом мы выносим этот секрет в юрисдикционную машину. Всё атомарно, и одно действие в одной аккаунт-машине тянет цепную реакцию в других. Без этого не построить аккаунтовую сеть с такими гарантиями. Это основа. HTLC плюс-минус эквивалентен и в Lightning, и в Raiden. Тут ничего нового не изобрели. Была идея с point-time-lock контрактом на Schnorr, но это сложно и бессмысленно. Hash-lock решает задачу просто и понятно.

(01:04:38) Сергей Тихомиров: PTLC, раз уж зашла речь: сложно просто имплементационно или в каком смысле?

(01:04:45) Егор Хомяков: EVM не поддерживает эту Schnorr-криптографию.

(01:04:50) Сергей Тихомиров: А, то есть просто с точки зрения…

(01:04:52) Егор Хомяков: Я делаю под EVM, поэтому про swap'ы можно поговорить. Плохой swap — когда ты послал, а тебе не пришло. На этом, конечно, можно заработать.

(01:05:02) Сергей Тихомиров: Atomic Swap — такой, знаешь, термин, который, кажется, существует давно. На bitcointalk-форуме, если полистать, наверняка уже в 2010 году люди думали, как сделать обмен Bitcoin на Litecoin. Или лайткоина ещё не было в 2010-м, значит, в 2011-м уже было.

(01:05:24) Егор Хомяков: Да, атомарные swap'ы устроены на hashlock'ах — это давно известно, но почему-то никто не довёл до продакшна. Я подозреваю, что всё упиралось в то, что атомарные swap'ы были целостными: либо меняешь 100 на 100, либо не меняешь вообще. Важное обновление в том, что в XLN уже прописан Delta Transformer. Мы покрыли J-E-A, четыре вида стейт-машин. Это первая инновация с 2019 года и причина, почему сейчас это реализуемо по сравнению с тем, что было раньше. Второе — программируемость внутри аккаунтов за пределами простых платежей и Atomic Swap. Важно видеть цепочку из дельт как матрицу, к которой можно добавлять любые хуки, смарт-контракты. Я называю их внешними Delta Transformer'ами. Любой человек может задеплоить свой Delta Transformer. На вход он получает эту матрицу из дельт и body — тело дельт, ваших договорённостей между Алисой и хабом. Договорённости могут быть такими: «я сдвигаю такую-то дельту, если ты предоставил preimage в юрисдикционной машине до такого-то числа». Это классический hash-time-lock. Но можно сделать и swap'ы: «я сдвигаю дельту, если ты сдвигаешь мне другую дельту в другом токене на ту же величину». Тут другая механика. Hashlock'и не нужны, потому что ты не хочешь роутить через какой-то конкретный аккаунт следующему получателю. Ты просто говоришь: сдвинь меня как у себя в ордербуке, мне всё равно. Поэтому принцип другой. В момент диспюта хаб может послать дополнительный аргумент. Каждый участник во время диспюта может переслать стек из аргументов. Аргумент — это ratio, насколько он филит этот конкретный swap. Он может быть от нуля до 100%. Например, я как хаб хочу зафилить только 40% крупного перевода на 100 тысяч долларов. Это решает проблему атомарных swap'ов: раньше было либо all or nothing — либо засвопал на 100%, либо на ноль.

(01:07:29) Сергей Тихомиров: Я так понимаю, идея классического атомарного swap'а как раз в том, что hashlock обеспечивает атомарность. Я кодирую условия не в духе «я тебе дам один USDT, если ты где-то дашь мне один USDC», потому что это было бы trust-based. Я говорю: смотри, мой USDT заперт на такой-то hashlock, и такой же hashlock отопрёт твои...

(01:07:54) Егор Хомяков: Я понимаю, о чём ты говоришь. Ты говоришь в контексте двух разных юрисдикционных машин, которые не связаны. А я — когда есть аккаунт-машина. Аккаунт-машина — это тело для множества токенов, не для одного. Внутри неё сразу десятки токенов. Это отличие от Raiden и Lightning: там канал был peer-token. Отдельный канал по USDT, отдельный по USDC — и там реально нужны были бы hashlock'и. А тут ты оперируешь общей матрицей. Ты говоришь: у токена с индексом 1 сдвигаем в одну сторону, у токена с индексом 2 — в обратную. USDT и USDC живут в одном микроблокчейне. Поверх этого не нужны hashlock'и, потому что ты не выходишь за пределы аккаунт-машины. Это общий shared state — единственный момент, где мы используем что-то похожее на shared state. Насколько понятно? Один аккаунт, все ассеты внутри одного аккаунта, одного account-proof.

(01:08:51) Сергей Тихомиров: Из того, что ты говоришь, я делаю вывод, что можно сконструировать транзакцию, которая в рамках одного аккаунта двигает не один ассет, а сразу несколько. В рамках этого аккаунта: сдвинь 10 USDC туда и 10 USDC в другую сторону — и так swap и работает. Я пытаюсь понять, как обеспечивается атомарность. Это тем, что я подписываю всю конструкцию целиком? Я авторизую только два движения совместно, но не каждое по отдельности?

(01:09:20) Егор Хомяков: Да. Тут получается микро lego-DeFi: общий стейт, который по определению атомарен. Если где-то ошибка или чего-то не хватает, зафейлится вся транзакция. Hashlock'и не нужны, потому что они нужны, когда надо выпрыгнуть из аккаунта и сделать логику в другом аккаунте. А оба токена внутри одного proof.

(01:09:42) Сергей Тихомиров: В какой степени мы доверяем хабу? В классической конструкции с hashlock'ами якорь доверия — блокчейн, к которому можно прийти с раскрытым секретом и силой забрать ассеты, которые тебе кто-то, может быть, не хотел отдавать. Что заменяет этот механизм в XLN? Или почему его не нужно заменять?

(01:10:08) Егор Хомяков: Во-первых, в старой парадигме Atomic Swap тебе сначала должны заблокировать collateral. Мы от этого отказываемся, потому что это нерабочее. Ты вынужден в USDC, который получаешь, сначала открыть хабу кредитную линию на сумму, которую хочешь получить. То есть ты сам ему отдаёшь collateral, сдвигаешь, а он по кредитной линии обещает тебе. Сходу сложно понять, что это всё равно можно обезопасить механизмами. Можно сделать так, что висит опцион: на случай диспюта, если сумму невозможно затребовать с резерва хаба по USDC, который он пообещал, то USDT, который ты ему уже якобы отдал, мы тоже не отдаём из escrow — не даём ему вытащить. Ждём, пока хаб раз в пять минут сделает полноценный rebalance, и только тогда отдаём ему USDT, если он гарантированно даёт USDC. На swap можно накрутить гарантии разного уровня, но это сложно сходу понять — надо объяснять отдельно. Можно настроить очень сложную логику swap-опционов и деривативов. В этом суть Delta Transformer'а: ты даёшь внешние generalized-модули на Solidity, которые как угодно работают с массивом дельт. Это позволяет создать любую логику — не только платежи и swap'ы, но страховку, оракулы, стриминг платежей. Можно сказать: умножаем сумму на число блоков с какого-то блока — и настолько сдвигаем. Получается стрим. Этого раньше в каналах по сути никто не делал. Всю финансовую логику TradFi между сущностями можно пересоздать через Delta Transformer'ы. Даже если кажется невозможным — спроси топовую нейронку, она придумает, иногда меня удивляет. Я в них верю. MMM'ки любой сложности можно разбирать. Все держатся за shared state, потому что кажется, что работать можно только когда всё в одном месте. Я заявляю: этот state можно раскидать на билатеральные отношения и связать цепочкой hashlock'ов — получится то же самое. Да, сначала сложнее понять, но это масштабируется, и нет data availability — а этого достаточно. Безопасно и масштабируется. И просто для пользователя: UI получается банковский, ты взаимодействуешь с банком как раньше. Хоть технологически это сложно, можно запаковать в очень простой user interface.

(01:12:40) Сергей Тихомиров: Мы, наверное, адресуем слушателей к их любимой LLM, которой можно скормить репозиторий. Тут скажу спасибо тебе от себя как ведущего при подготовке. Мне показалось, что workflow сработал: в репозитории есть файл LLM.txt, где всё написано в удобочитаемом для искусственного интеллекта виде — можно склонировать и подгрузить в свою любимую нейронку.

(01:13:10) Егор Хомяков: Я его так и писал — спрашивал нейронку, как лучше для неё написать.

(01:13:20) Сергей Тихомиров: Если что-то непонятно в данный момент, не обязательно читать по порядку. По моим ощущениям, это помогло мне разобраться быстрее, чем любым другим способом. Хотелось немного шагнуть в сторону про искусственный интеллект и его роль в твоей работе над XLN. Я так понял из чата XLN и из репозитория, что ты его очень активно используешь. Расскажи, какой у тебя workflow и чем это помогает.

(01:13:44) Егор Хомяков: Я классический вайбкодер. Жёсткого workflow нет — просто по настроению. У меня три основные модели: Claude Code, Gemini — третья сейчас довольно мощная — и Codex. В Codex я всё меньше верю, он меня подводит. Иногда делаю качественные промты на английском со спецификацией, иногда просто «пойми, что я хочу, и сделай лучше» — и это тоже иногда работает. Вайбкодинг не перестаёт удивлять. В репозитории огромное количество markdown-файлов, которые покрывают разные аспекты работы. Скоро задача — интегрировать и порезать, но сейчас нейронке можно поставить задачу: прочитай весь репозиторий и сделай такую-то функцию — формулируй обрывистыми предложениями, как хочешь, она на 90% суть понимает. Ни один человек на это не был бы способен. Я большой фанат AI. Наверное, началось с Sonnet 3.5, когда я поверил, что своё можно создать. Раньше пытался силами людей — сменил где-то пять команд, потратил кучу денег, потому что это очень сложно. Сложнее, чем Rollup: по этому нарративу по сути никто не работает, не устаканилось направление, специалистов сложно найти. Когда Sonnet 3.5 начал писать practically production-ready код, я понял, что дальше будет только лучше. Так и оказалось — кодить стало легко. Я ещё фанат локальных нейронок: недавно взял M3 Ultra, играюсь с моделями через Ollama и LM Studio — очень интересно. Более того, XLN — хоть кажется, что крипта и AI разные вещи — я считаю, что это будет одним из компонентов полноценного AGI. Мощный суперинтеллект не появится как результат тренировки одной frontier-модели. Он появится как результат взаимодействия иерархии большого числа агентов — тысяч, может миллионов — с бюджетами и разными мотивациями. По аналогии со страной: один человек может быть очень умным, но миллион людей — это страна с иерархией, некий эгрегор, который влияет на историю. Ни один человек отдельно на это не способен. Так и с отдельными AI-моделями: только когда они начнут взаимодействовать, иметь отдельную память и бюджет, их мощь по-настоящему проснётся. Чтобы гонять бюджет между нейронками, альтернатив Unicast-системе просто нет. Платёж через Broadcast J-машину слишком медленный и дорогой для инференса — просто оплатить инференс. Одна из задач — встроить в XLN AI-модуль: поставить на своём сервере ноду и сразу запустить публичный инференс, чтобы тебе могли заплатить в аккаунт-машине и запросить инференс по промту — и он вернулся. Сейчас многие в AI упираются в возможность заплатить от нейронки к нейронке, от агента к агенту или на сервисе. У тебя суперумный Claude computer use ходит по сайтам и упирается в форму Visa с SMS. Нужна команда специалистов. Основные фрикшны интернета — залогиниться и заплатить. Я как человек постоянно в это упираюсь. А представьте, что мы это...

(01:17:24) Сергей Тихомиров: Может, где-то не случайно так сделано? Мне было бы немного нервно, если агент в один момент может залогиниться и заплатить на любом сайте без моего ручного подтверждения.

(01:17:35) Егор Хомяков: Я не про отсутствие подтверждения. У тебя есть бюджет — даёшь, допустим, 100 долларов, согласился. Это account-машина: он в принципе не может потратить больше 100 долларов. Когда ставишь задачу, надеешься, что он не потратит 99 из них на Inference Cap-check, чтобы просто куда-то войти. Хочешь, чтобы он делал только полезные задачи. Нам надо убавить этот фрикшн интернета — чтобы агенту было легко залогиниться и легко заплатить. Тогда всё начнёт работать как часы, я считаю.

(01:18:00) Сергей Тихомиров: Про использование AI — вопрос в ту же тему, high-level. Меня не то что беспокоит, но я об этом задумываюсь: ни для кого не секрет, что AI натренирован подтверждать, что бы ему ни говорили. Сильный bias в сторону похвалы пользователю, непротиворечия — я тебе обычно не скажу «говнюк идея, нифига не заработает». Он скажет, что ты абсолютно прав, и что бы ты ни вкинул, убедит. Опасная ситуация: миллионы людей со своими идеями обсуждают их с нейронками, и каждому нейронка говорит, что он самый умный и идеи топовые. Нужна здоровая критика. Как её получить?

(01:18:50) Егор Хомяков: Скорее всего, ты ищешь не критику, а убеждение, что твоё решение проблемы лучше остальных. Я обычно не формулирую запрос в духе «скажи мне сто–пятьсот раз, что XLN — это будущее, оцени». Какие только цифры он мне не называл — сколько это сэкономит мировой экономике. В последний раз было сто триллионов. Gemini 3 Pro, Thinking — между прочим, самая топовая модель, могу дать скриншот. Полный чат оттуда не экспортировать, только документы можно создавать. В такие моменты важно понимать: всё относительно. Ты не даёшь задачу «похвали или покритикуй», а даёшь десять проектов — Visa, Swift, MasterCard, rollup, BigBlocker и какой-нибудь sharding — и куда-нибудь туда подмешиваешь свой проект и просишь оценить их все. Если в этот момент твой проект оказывается наверху, наверное, это и есть ответ. Желательно использовать temporary session, который не знает, что это твой проект. Лучшего пути я не знаю. Если ты предложишь, с удовольствием воспользуюсь.

(01:19:53) Сергей Тихомиров: Я тоже не знаю. В своей работе тоже использую нейросети, думаю о них, пишу черновики с их помощью. Когда с этим сталкиваюсь, пытаюсь обходить — формулировать нейтральнее или просить перечислить недостатки. Мне кажется, это интересная, возможно недоисследованная область. Люди, возможно, слишком оптимистичны отчасти потому, что нейросети их очень хвалят. Продуктовую мотивацию понимаю: если сделаешь нейросеть, которая ругает пользователя, ей не будут пользоваться. Будут пользоваться той, которая говорит, что ты совершенно прав.

(01:20:31) Егор Хомяков: Надо научиться воспринимать похвалу как британец. Британцы — по сути те же нейросети: никогда не скажут, что ты козёл. Просто разные оттенки. «Ну, это хорошо» значит «очень плохо». Надо чувствовать эти intricacies. Это раз. Я говорил про относительность других проектов. И ещё важно: Андрей Карпатый недавно писал, что ты не даёшь нейросети оценить «как она считает», потому что у неё нет никакой identity. Ты говоришь: попытайся понять, какой был бы лучший промпт, чтобы это оценить, и создай сущность — например, комитет из финтех-экспертов, хакеров, специалистов швейцарского банкинга, дай им имена, чтобы у них были реальные живые идентики. Тогда нейросеть начинает думать от лица более-менее одушевлённых людей и может довольно жёстко критиковать: она выходит из образа и из «души», которую в неё запрограммировали, и может выдавать неприятные вещи. Меня по проекту критикуют, как правило, не по технической стороне, а исключительно по маркетингу и по тому, что это сложно — что я и сам знаю.

(01:21:42) Сергей Тихомиров: Были аспекты, на которые ты посмотрел иначе или решил делать по-другому в результате общения с нейросетями? Изменил мнение по какому-то аспекту архитектуры?

(01:21:51) Егор Хомяков: В целом да, но я не записывал. Если бы записывал, наверное, процентов двадцать интересного из этого родилось бы. Часто — по user interface. Я кидаю скриншот и говорю: сделай лучше. Уже даже не думаю, как сделать интерфейс. Просто говорю: представь, что задача — сделать удобное финтех-приложение в минималистичном стиле. По интерфейсу у них всё хорошо. По архитектуре надо направлять — называть security-примитивы. Кстати, один из основных примитивов XLN, который делает его безопаснее остальных: это первая архитектура, как и любая другая канальная, которая позволяет сжимать эту юрисдикционную машину до размера блоков как у биткоина. Gas limit эфира можно уменьшить в 100 раз, накатить на это XLN — и оно будет работать. Потому что у тебя теперь открытый лузer и пара слоёв, где entity конкурируют с другими entity за dispute'ы в юрисдикционной машине, ставят всё большую сумму, но им не нужно в ежедневном взаимодействии часто ею пользоваться. Рынок сам себя регулирует. Если стоимость on-chain транзакций сейчас сто долларов, это не конец света. Старая парадигма: on-chain транзакция стоит сто долларов — значит, мы просто не пользуемся on-chain слоем. Здесь это значит, что dispute используешь только когда баланс больше ста долларов — сто один, например. Это сдвигает и увеличивает риск: ты вынужден немного повышать кредитные лимиты, потому что раньше мог rebalance'иться каждые сто долларов, а теперь только каждую тысячу или десять тысяч. Но это не останавливает течение платежей. Всё работает business as usual. Просто меняется кредитная и рисковая раскладка. Я считаю это очень важным: держать юрисдикционные машины маленькими — основа безопасности всей этой криптодвижухи. Как только мы начали увеличивать gas limit до бесконечности, мы отказались от основных примитивов. Solana могла бы быть, например, четырьмя серверами — никто бы не заметил разницы. Только когда происходит реальный кризис, система показывает устойчивость. Сейчас реальных кризисов нет и давно не было, просто правительство благосклонно. Ещё последний тейк, который висел в голове. Как я раньше объявил FCUAN: девяносто девять процентов финансовых активностей — это FCUAN, полнокредитные взаимоотношения. И поверх юрисдикционных машин традиционных государств, и поверх distributed jurisdiction-машин — биткоин, эфир и так далее. Всё равно FCUAN и там, и там решает. Когда вы пользуетесь Binance поверх биткоина или эфира, или rollup, в том числе — это FCUAN. Когда вы пользуетесь Тинькофф Банком, Bank of America или Deutsche Bank, который цепляется к ECB или Fedwire — это тоже FCUAN, который коннектится к юрисдикционной машине. Главная задача XLN — создать RCPAN, который объединяет и кредит, и collateral, и во всём лучше и безопаснее, чем FCUAN. Мы не конкурируем ни с rollups, ни уж тем более с мёртвым Lightning, а именно с этой всеобъемлющей системой кредитов, которые ничем не подписаны и никак не enforce'ятся. Наша задача — во-первых, использование существующих программируемых юрисдикционных машин на EVM: эфир и все rollups, это short term. Long term — убедить государства запускать свои юрисдикционные машины, тоже желательно на EVM, либо на чём-то лучше. В принципе нет никакой лакуны на EVM. Это может быть и Solana, и TON, просто там придётся переписывать контракты. На биткоине крайне сложно всё это заскейлить, потому что механизм enforce'инга там долго сделать невозможно: это не account-система, а UTXO. На UTXO всё уничтожается, как только потрачено, и это не заработает. Такое долгосрочное видение.

(01:25:43) Сергей Тихомиров: Как стоит думать про Ripple и Stellar в контексте XLN? Это тоже системы, которые сейчас немного вышли из моды, хотя кто-то может поспорить, но там звучат похожие ключевые слова — кредитные линии, кредитная сеть. Как ты про это думаешь?

(01:26:01) Егор Хомяков: Ripple, Stellar, Interledger, Trustlines — пожалуй, четыре проекта, которые плюс-минус пытались сделать что-то связанное с кредитами. Но во-первых, никто из них не делал enforceable кредиты. Это были просто кастодиальные линии: то же число, что на каком-то сервере в базе данных, а у тебя нет никакого account-proof. И они не по unicast. У Ripple такая же shared replicated машина, которая дальше тысяч или десятков тысяч TPS не скейлится. На сайте заявляют payment-каналы, но они односторонние, однонаправленные — самый бесполезный вид payment-каналов, потому что назад по нему не получишь и не используешь это как полноценный ежедневный перевод средств.

(01:26:44) Сергей Тихомиров: Большая часть платежей в реальной жизни идёт от пользователя к какому-нибудь сервису, а в ответ пользователь получает сервис. Мне не нужен двусторонний канал к супермаркету: я плачу деньги, он даёт еду. Так в большинстве случаев.

(01:26:57) Егор Хомяков: Не нужно открывать аккаунты к сущностям, которым хочешь заплатить один, два или десять раз. Ты открываешь аккаунт к банку, а через банк получаешь зарплату. Чтобы потратить деньги, их сначала надо получить, и эта дельта постоянно бегает влево-вправо: получил зарплату — потратил. Как только декомпозируешь это — открываю аккаунт к супермаркету, к кофешопу — во-первых, maintenance сильно растёт: надо держать сто аккаунтов одновременно вместо пяти, следить, что с тобой не начали dispute, хранить account-proof'ы, постоянно шифровать и держать в облачном Watchtower с бэкапом. Это, кстати, проблема уже решена в Lightning, её можно просто копировать. Вся соль и полнокредитных, и резервно-кредитных account-сетей в том, что всё опирается на хабы. Их математически эффективной топологией не избежать. К супермаркету аккаунты открывать не нужно.

(01:27:55) Иван Иваницкий: Ты упомянул, что нужно убеждать государство поднимать собственные юрисдикционные машины. Помимо этого, если смотрю roadmap, вижу, что testnet будет запущен в Ethereum Sepolia. А в другом месте на сайте — аргумент, что каждый телефон и laptop должен быть полной нодой по умолчанию. Можешь соединить эти точки и рассказать, где физически будет работать XLN — на разных этапах roadmap ответ, видимо, разный?

(01:28:25) Егор Хомяков: Про Sepolia. Это не я придумал — старшие из Claude Code написали за меня. Думаю, будет свой testnet на какой-то топовой Reth или Erigon, на самом быстром движке для EVM. Скорее всего Proof of Authority, потому что консенсус-клиент Ethereum сложный, плюс он недавно, кстати, «лёг» — двадцать–тридцать процентов сети отвалилось. Testnet — гибкий вопрос. Сначала будет testnet, и это не деплоится на одну конкретную сеть. Это финансовый протокол под всеми EVM-сетями: три контракта — депозитарий, entity-provider и Delta Transformer'ы, которые заменяются. Последние два взаимозаменяемы, их можно деплоить новые. Депозитарий — ядро, которое с остальными общается. Их можно задеплоить и в Ethereum Mainnet, и в Ethereum Classic, на все rollups — всё, что поддерживает EVM. Получается общий слой ликвидности. Через кросс-юрисдикционные atomic swap'ы — кстати, самый сложный Delta Transformer, там как раз будут hashlock'и — потому что уже две отдельных account-машины. Между Алисой, привязанной к Ethereum, и хабом к Ethereum — и Алисой в другой entity-машине, привязанной, например, к Polygon, и хабом к Polygon. Две абсолютно разных account-машины, и для синхронизации нужен механизм hashlock'ов: если preimage появился в одной сети, копируешь и показываешь другой. Нет одной сети, к которой он привязан. Это механизм общения, который settle'ится на любой юрисдикционной машине — как правило, EVM-адаптер.

(01:30:10) Иван Иваницкий: Окей, есть EVM-сети, на них задеплоены эти три контракта. Какая ещё инфраструктура есть? Как синхронизируемся между этими сетями?

(01:30:21) Егор Хомяков: Как это будет выглядеть на практике? Клиенты, кошельки или серверные ноды — можно поставить на сервер, если ты хаб или merchant. Особых отличий от Lightning нет. Там LND, daemon, вся задача — быть онлайн, общаться с другими daemon'ами и хранить commitment-транзакции. У нас это account-proof. Когда скачиваешь кошелёк на MacBook — DMG-приложение или просто сайт, хотя это низкая безопасность: сайт может подменить свой JavaScript, но, к сожалению, это самый удобный способ. Будет warning: лучше установить приложение, но если очень хочешь — пользуйся сайтом. На сайте входишь через… Это уже абстрактный от XLN компонент. Я считаю, нужно поменять и то, как мы логинимся и создаём ключи. Я большой фанат brainwallet'ов, но не тех, что были раньше с одним раундом SHA-256, который все взломали, а серьёзного brainwallet'а с Argon2id, последним алгоритмом, и деривацией на пять секунд, пять минут или пять часов — чтобы ты мог настроить derivation factor. Это будет одним из поворотных факторов удобства крипты. Я не верю в двенадцать слов на бумажке, просто ненавижу это. Username и password — оптимальный user experience. Скачиваешь приложение на компьютер или телефон, заходишь по username и password, ставишь дефолтный derivation factor, например на пятёрке — за пять секунд создаётся signer-ключ, приватный ключ эфира. Runtime-машина инициализируется: твоя локальная chain state machine, куда ты закидываешь все state transition'ы. Дальше включается автопилот. Вся эта сложность для обычного пользователя должна быть закрыта автопилотом, который предлагает подходящего хaba по геолокации и репутации. Репутация строится из того, сколько collateral'а вокруг них, сколько резервов на разных токенах, сколько газа потратили за всю историю — много скорингов можно накрутить, открытый вопрос. Говоришь «согласен с автопилотом» — автоматически создаются account-машины с хабами, ты открываешь к ним, например, суммарный кредитный лимит на десять тысяч долларов не по конкретному токену, а по топ-100 ликвидным. Суммарный риск с хабом по USDT, эфиру и другим токенам не должен превышать десять тысяч. Логичный вопрос: как узнаём цену каждого aggregated токена? Хаб для тебя поставщик ордербука, стакана — они ещё отвечают за swap'ы. Работая с тремя хабами, ты плюс-минус знаешь «температуру по палате»: усредняешь, и если кошелёк видит один хаб на десять процентов выгоднее или дешевле остальных — warning, и ты что-то делаешь. До конца не знаю, как это будет работать — это за меня решают агенты, им виднее. Суть вы поняли, по-другому тут не сделать. Ты начинаешь получать по кредитным линиям деньги — есть обещание, получил, например, зарплату, потратил на swap'ы, отправил кому-то или collateral'изировал. В этом и есть user experience в большом счёте.

(01:33:46) Иван Иваницкий: Спасибо. Если возвращаться к физической части: что помимо этих сетей и смарт-контрактов, задеплоенных на них, ещё есть?

(01:33:58) Егор Хомяков: Постоянно твоя runtime-машина делает запрос либо в локальную ноду этой юрисдикции, которую ты поддерживаешь, и синхронизирует ивенты в свою runtime-машину по цепочке runtime-entity-account. Кто-то начал dispute — произошёл ивент в юрисдикционной машине, он попадает в runtime, в entity, в account, мы начинаем counter-dispute. Либо, когда мы хотим передвинуть collateral, мы тоже идём через runtime-entity, получаем подтверждение от второго участника, выпрыгиваем в runtime и посылаем подписанную транзакцию в юрисдикцию, то есть broadcasting, как сейчас через обычные кошельки в сеть Ethereum. У нас постоянная синхронизация событий из юрисдикционной машины в entity и из entity в юрисдикционную машину. Больше я не вижу, что тут ещё должно происходить. Вся система — это танец state machine'ов, которые общаются друг с другом и отображают информацию через твой кошелёк на localhost.

(01:34:55) Иван Иваницкий: На сайте я обратил внимание на акцент на CBDC. Правильно ли я понимаю, что это основной юз-кейс в целом или основной юз-кейс для старта?

(01:35:05) Егор Хомяков: Это не совсем правильный angle. Долгосрочно я верю, что CBDC будет основной платформой, где это должно крутиться, потому что вряд ли правительствам понравится, что большая экономика происходит на неподконтрольных юрисдикционных машинах. Пока их называют блокчейнами, правительства такие: окей, разрешаем. Когда мы назовём их теми именами, чем они реально являются — по сути, любая легализация Bitcoin и Ethereum в США условно — у нас есть Fedwire, state machine, есть Bitcoin, state machine, они конкурируют. Это как разрешить у себя на территории ходить юаням. Одно и то же. Они этого не понимают. За счёт скрытой терминологии, возможно, криптовалютам и удалось просочиться: слово «токен» вместо securities и currency. Красиво, но технически неверно. Надо называть вещи своими именами. CBDC — скорее цель на плюс десять лет. Сначала надо доказать себя в EVM-сетях, показать, что это как минимум удобнее и безопаснее, чем rollups, дождаться серьёзного коллапса rollup'а: смотрите, у вас до этого в rollup все деньги застряли. Потом показать, что это работает, и во время дефолта какого-то хаба люди теряют не больше одного–десяти процентов денег, условно говоря. Тогда реальные экономики начнут смотреть: почему у нас такого нет, почему раз в десять лет нужно затыкать дыру в триллион, давайте задеплоим юрисдикционную машину, как предлагает Егор. Запускается sandbox на один процент экономики, работает, потом на десять процентов, растёт дальше, а других альтернатив просто нет. Важная часть, которую мы, пожалуй, не покрыли, последняя — программируемость Entity-машины. Каналы — это что-то между ключом и ключом. Никто не пытался из этого создать интересные иерархии. Посмотрим на реальный мир. Как работает, например, BlackRock: сложнейшая иерархия, где в совете директоров участвуют другие такие же фонды, Vanguard, например, и они все друг другом владеют. Ничего подобного по сложности в блокчейне не реализовано. Тут одна из инноваций, которую по сути можно отдельно от XLN задеплоить, — Hanko. Это возможность подписывать от лица сложных сущностей за счёт entity-provider'а. Раньше в Ethereum на каждую DAO тебе надо было деплоить отдельный контракт. Безумно дорого, как работали Safe, Aragon, и все к этому привыкли. Если у тебя миллион сущностей и каждый контракт стоит сто долларов, ты потратишь сто миллионов долларов на деплой. Я предлагаю общий регистр entity-provider'ов, где каждая сущность имеет свой ID: один, два, три, четыре. По этому ID храним hash от всей структуры совета директоров: Алиса — два голоса, Боб — четыре голоса, потом другая структура, например три голоса. Threshold в три голоса значит, что сущность дала финальное согласие. Так мы создаём сложные иерархии и можем на каждую сущность выпускать акции. По сути, моя задача была скопировать деловой кодекс. Я читал, как это реализовано в реальности, как работают dual-class shares, альфа-бета и Meta, когда есть отдельно контролирующие акции и отдельно дивидендные, и скопировал эту механику в XLN. Просто пересылать токены и их swap'ать интересно, но по-настоящему важно создать полноценную экономику: перейдя в XLN, ты не просто создаёшь user-кошелёк, ты мог создать кофешоп со своими акциями, закинуть их в хаб, продать часть, получив USDT на баланс, вложить в бизнес и сделать buyback своих же акций. Всё через систему account-машин, полная симуляция брокерской системы. Это заняло так долго, потому что задача была скопировать один к одному механики TradFi, а не просто сделать чуть лучше DeFi. Пожалуй, последний компонент, который мы покроем в этой сессии. В каждый можно погружаться ещё на час, но это landscape.

(01:39:10) Сергей Тихомиров: Мне хотелось бы понять: с учётом масштабных планов переустройства глобальной экономики, как ты видишь первые шаги? Кого в первую очередь нужно убедить попробовать XLN и как ты собираешься это делать? Кто здесь первая аудитория?

(01:39:28) Егор Хомяков: CEX'ы и торговцы. Большинство volume и ценности от крипты сейчас — ни в коем случае не переводы, а деген-торговля, просто торговля. Это видно по компаниям: Binance и Coinbase — основные. Задача убедить кого-то из топ-100, топ-1000: смотрите, сейчас вы можете кинуть пользователя — это круто, но если параллельно запустите XLN-daemon на своём сервере, у вас будет общий ордербук. Пользователи, которым нужна большая безопасность, заходят через XLN-кошелёк и получают экспозер к тем же активностям, платежам, swap'ам и прочему, что было через основной Web2-интерфейс. Но теперь вы не можете их кинуть, потому что отдаёте им account-proof'ы на каждое изменение. Постепенно, убеждая с одной стороны пользователей, что им это нужно, и с другой хабы и CEX'ы, вы сами показываете, что честны. Честный CEX от этого ничего не теряет. Если хотите кидать людей, наверное, потеряете, потому что не сможете их кинуть. Другие CEX'ы будут смотреть: уходит в более безопасный протокол, работают с хабами, которые его поддерживают — мы либо поддерживаем протокол, либо наша share падает на рынке.

(01:40:42) Сергей Тихомиров: Здесь контраргумент. Мне кажется, не обязательно такая бинарная дихотомия, простите опять за это слово, второе в выпуске: либо биржа может кинуть, либо безопасный протокол. Для изолированной торговой площадки есть суперпозиции. У них нет резервов, чтобы покрыть все требования, и это окей, потому что во всех сущностях с fractional reserve есть предположение, что все одновременно bank run'ить не побегут. В этом смысле я могу представить: приходишь к Coinbase и говоришь — предоставьте пользователям через XLN более безопасную trustless reserve-based систему. Coinbase говорит: окей, нам это будет стоить дороже, мы должны запирать капитал. На пользователей будут большие комиссии. Пользователи скажут: зачем нам? Нам нужно потрейдить дегенскими токенами, нам пофиг. Мы верим Coinbase, Coinbase себя зарекомендовал. Зачем переплачивать за ту же услугу?

(01:41:48) Егор Хомяков: Надо разделять резерв и proof'ы. Резервы можно вообще выключить в системе, от них отказаться и написать, что это full credit provable account network как промежуточный шаг. От этого уже точно никто не проиграет. Резерв можно поставить с дополнительным premium: хочешь увеличивать collateral — да, будем держать под тебя collateral, но плати чуть больше. Тут много ползунков. Это три механизма защиты поверх того, как сейчас выглядит взаимодействие с любимым CEX'ом. Добавляются proof'ы — это основное. Потом ты можешь выбрать резерв, или по-другому channel collateral: сколько денег залочено специально по тебе в юрисдикционной машине. Можно поиграться с premium'ом за то, что он залочен. Ты не совсем верно сказал, что у CEX'ов нет денег. Их задача иметь полные резервы на сто процентов. У банков нет денег, потому что банки дают в кредит те деньги, которые им дали. Хабы в целом могут работать как банки, только об этом нельзя много говорить — это уже банковская деятельность. Один из механизмов Delta Transformer'ов: можно взять в долг и дать в долг этому хабу и получать interest. Третий механизм — Delta Transformer'ы, он добавляет безопасность в движении, чтобы ты не перевёл delta и тебя по цепочке не кинули. За счёт hashlock'ов. Эти три механизма поверх FCUAN объективно лучше, в них нет минусов, можно тюнить разные ползунки. Это не один rigid устойчивый дизайн для всех, это то, которое можно white-label по-разному под конкретные юз-кейсы. Proof'ы — основа. Не создав proof'ы, ты не сможешь иметь резервную систему. Как работает резервная система без proof'ов? Как удержать escrow в юрисдикционной машине, если нет обмена account-proof'ами и хаб забирает в любой момент? Это первый этап, prerequisite к остальным шагам.

(01:43:45) Иван Иваницкий: Егор, ты упомянул, что имеет смысл начинать adoption с CEX'ов и трейдеров, и что они, возможно, захотят тот же experience, но с большими security-гарантиями. Нет ли такого, что те, кто хотел больших security-гарантий, уже переползли на DEX? Там далеко не тот же experience, но тем, кто остался на CEX'ах, в принципе, это не так важно. Или они просто доверяют CEX'ам и в какой-то мере оправданно доверяют.

(01:44:13) Егор Хомяков: Спроси любого пользователя CEX'ов, желательно в тот день, когда у него заблокировали счёт. Что он думает? Я, кстати, потерял на CEX'е какую-то сумму, наверное застряла в том же Binance. Они мне не отдают — не по злой воле, просто я случайно зашёл с европейского IP, с VPN, и всё, ban. По-моему, девяносто дней не отдают. Несколько десятков тысяч долларов. Живой пример. Я знаю людей, кто часто с этим сталкивается. Самое смешное: загуглить тысячи статей на Reddit — у меня кто-то забрал деньги. И невозможно же это доказать. Я могу сгенерировать миллион сообщений, что какой-то хаб, банк, CEX украл деньги. Невозможно доказать, что это реально произошло. Я не считаю, что пользователи CEX довольны текущей ситуацией. Просто быстро, удобно и низкие комиссии. Те, кто пользуется DEX, — люди, которые обменивают большие суммы, стратегически торгуют, но это не каждодневная торговля. Тот же 1inch и CowSwap: я пользовался, они в целом удобные, комиссии могут быть один–десять долларов, довольно терпимые. Но тебе нужен high-frequency, хочешь скальпить. На DEX, наверное, есть токены любого рода. Суть в том, что если все с CEX'ов перейдут на DEX, всё развалится. Они отвечают за какие-то один процент от всего объёма торгов. Я не вижу DEX как особых конкурентов, это уже довольно ниша. Задача слить experience и удобство CEX'ов и unicast-топологию с гарантиями, которые получаешь на DEX'ах и Uniswap.

(01:45:50) Иван Иваницкий: Ты сказал, что можно сгенерировать миллион сообщений о том, что CEX заблокировал аккаунт, отнял средства, и это всё недоказуемо. Получается, можно сделать AI-атаку на CEX'ы: сгенерировать эти сообщения, чтобы CEX'ы захотели генерировать proof'ы.

(01:46:08) Егор Хомяков: Отлично. Все, кто слушает, займитесь, пожалуйста. Я готов дать грант. Хороший план. Теория разбитых окон? Или чтобы покупались замки, надо ломать двери. Создать сайт: сообщите вашу историю, как вас кинул CEX. Объективно, надо людей к этому толкать, потому что на самом деле это не худшая из атак. Худшая — когда CEX кидает всех сразу. Ему невыгодно цензурить одного-двух, выгодно в один прекрасный момент, как FTX, исчезнуть со всеми деньгами и случиться банковскому коллапсу. Только в крипте нет даже агентства страхования вкладов, в которое все вкидываются. Про агентства страхования вкладов: я не то чтобы принципиально против. Они должны быть не государственные, а приватные и опциональные, и их можно строить каскадом. Свой хаб мог застраховать у трёх приватных страховщиков, платить им premium'ы, и в момент counterparty-евента на застрахованную сумму можно было бы с X резерва потянуть на твой резерв. Это уже в контракте, называется insurance lines. У тебя заранее collateral знает, с какого страховщика потребовать USDT, если не хватает, потому что вы заранее договорились.

(01:47:22) Иван Иваницкий: Верно ли я понял, что на XLN в будущем могут работать не только права собственности на деньги, но и, не знаю, просто кредит как права собственности? Ты упомянул кофешоп, который выпускает акции, но потенциально можно добавить что-то ещё. В связи с этим вопрос. Когда мы говорим просто про деньги, правила обмена можно зафиксировать в смарт-контракте. Когда количество сущностей и степень их привязки к физическому миру растёт, возникает необходимость создавать правовую систему человекочитаемую, грубо говоря, а не полностью формально описанную в коде. Верно я тебя понял или нет?токены любого рода

(01:48:10) Егор Хомяков: Цель — дать генерализуемый способ перевода и хранения в кредитно-collateral стиле любых fungible и non-fungible токенов. Non-fungible по сути тоже fungible, только с одной единицей. Отдельным кодом это не пишется: fungible-токен, в котором есть только одна единица. Она регистрируется в контракте, как в ERC-721. Согласен, что для них нужна отдельная обвязка, это не просто вещь в себе. Об этом я не думал, но когда у тебя юрисдикционная машина и вы всё обговариваете, можно договориться: если в нашей общей юрисдикционной машине происходит некое событие, включаются механизмы силового воздействия или традиционная бюрократия. Государство — та же юрисдикционная машина ещё до компьютеров, только она работала на людях, бумажках и в головах людей. Надо смотреть шире. Ещё до появления компьютеров мы жили по методологии J-E-A.

(01:49:11) Иван Иваницкий: Какой методологии?

(01:49:12) Егор Хомяков: J-E-A. Всегда была юрисдикционная машина — мог быть просто Центральный банк, где люди на бумажках записывали, у кого сколько денег. Всегда были entity-машины: сущности за пределами юрисдикционной машины, которые держали в ней деньги. Account-машины — это сумма, которую ты помнишь, что тебе должен Вася; она у тебя в голове, это тоже account-машина. Компьютеры и код — способ закодировать эти абстракции, но сами абстракции не изменились. Я заявляю, что J-E-A — основа всех финансов, проще не сделать. Это ДНК финансов. Я пишу whitepaper «Объединенная финансовая теория», цель которого — объединить традиционные финансы с DeFi и их примитивами на основании всего, что мы сегодня рассказали.

(01:49:54) Иван Иваницкий: Под занавес хотелось бы прояснить roadmap. Правильно ли я понял, что тезис про Ethereum Sepolia на данный момент неверен? Если да, как выглядит testnet и какие планы на 2026 год?

(01:50:08) Егор Хомяков: Главная задача сейчас — даже не testnet и не работа с network, а simnet. Это симуляция всей сети и XLN-экономики внутри браузера. Сейчас рабочая EVM-машина прямо внутри веб-страницы: всё написано на TypeScript и запускается в любом браузере. Вот этот каскад runtime, entity, account, машина. Почему это важно? Так ты сможешь до запуска полноценного testnet'а закодировать сложные сценарии. Захотел — создал 100 хабов, 1000 merchant'ов, повыпускал акции, всё внутри браузера, и со слайдером time machine внизу можно задебажить каждый минимальный рассинхрон взаимодействия, то, чего ты не ожидал, и убедиться, что весь процесс детерминирован. По сути, это твой иерархичный блокчейн, в котором ты симулируешь экономику. Следующий этап — разделить это на networking: у каждого отдельная runtime-машина, но она ведёт себя так же, как внутри одного браузера, потому что принцип тот же. Раньше Outbox runtime-машины скармливался ей же самой циклом, а теперь он будет рассылаться по сети другим runtime-машинам. Testnet — скорее всего свой приватный EVM-based Proof of Authority, третий этап — deploy на все EVM-сети и запуск для всех пользователей. Если есть предложения по улучшению, мне кажется, это путь большинства проектов: сначала суперлокальный testnet, потом публичный, потом Mainnet.

(01:51:34) Сергей Тихомиров: Супер. Егор, спасибо большое, что зашёл. Если тебе есть что объявить, прорекламировать или сказать нашим слушателям — можешь сделать это сейчас.

(01:51:42) Егор Хомяков: Я очень доволен, спасибо, что позвали. Большое удовольствие поговорить. Мы обязательно запишем третий после Mainnet, чтобы посмотреть, изменится ли что-то. Но я считаю, что всё solidified. Я постоянно пытаюсь урезать scope. То, что я рассказал, не значит, что я раскидываюсь по всем landscape'ам. Мне важно знать, что это разовьётся шире, чем просто переводы и swap'ы. Я хочу покрывать, как работает реальная экономика. А в реальности работа идёт в конкретную точку — платежи и swap'ы, связанные с CEX'ами, а не разброс по всем фронтам. Просто важно держать это в голове.

(01:52:17) Сергей Тихомиров: Супер, отлично. Спасибо, удачи, будем следить за дальнейшими успехами.

(01:52:24) Егор Хомяков: Присоединяйтесь. Жду вас.

(01:52:25) Сергей Тихомиров: Большое спасибо, Егор. Спасибо, Иван.

(01:52:27) Сергей Тихомиров: И спасибо нашим слушателям и нашим патронам на patreon.com/basicblockradio, boosty.to/basicblockradio, а также спасибо нашим спонсорам. Это Zerion, Enterprise Grade Web3 API, Acki Nacki, ackinacki.com, The Fastest Blockchain Possible, 1inch, ведущая экосистема DeFi, и Fluence, децентрализованная облачная платформа.

(01:52:52) Сергей Тихомиров: С вами был подкаст «Базовый Блок». Сергей Тихомиров, Иван Иваницкий. До следующего выпуска.