Обсуждаем избранные доклады конференции MIT Bitcoin Expo: как работает и зачем нужен Taproot, как контрибьютить в Bitcoin Core и чем опасны недетерминистичные билды кошельков.
Таймкоды:
- 00:00:29 благодарность патронам и спонсорам
- 00:03:29 конференция MIT Bitcoin Expo
- 00:06:30 доклад Andrew Poelstra про Taproot
- 00:17:05 MAST — масштабируемость или приватность?
- 00:21:26 почему Taproot и Шнорр идут в одном апдейте
- 00:28:12 почему MAST не имплементировали в 2012
- 00:30:00 доклад James O’Beirne: Contributing to Bitcoin Core
- 00:32:15 Assume UTXO: проект для оптимизации изначальной загрузки блоков
- 00:37:56 зачем нужно оптимизировать, ведь там всего ~280 Гб?
- 00:44:09 доклад Jeremy Rubin про BIP 119 Checktemplateverify (CTV)
- 00:50:06 сравнение CTV с Ethereum
- 00:56:33 как CTV позволит биржам дискриминировать клиентов
- 00:58:01 доклад Tadge Dryja «Node Modes: Taxonomy of Bitcoin Network Nodes»
- 01:03:07 проект Tadge Dryja U3XO
- 01:07:14 доклад What is Bitcoin Being Used For и почему суммы биткоин-транзакций перестали быть круглыми
- 01:14:34 доклад Jameson Lopp: The Promise and Perils of Non-Deterministic Bitcoin Scripts
- 01:19:25 благодарности
Ссылки:
Спасибо нашим спонсорам:
- Подкаст выходит при поддержке Zerion – понятного интерфейса к DeFi-протоколам.
- Подкаст выходит при поддержке HodlHodl – площадки для покупки и продажи биткоинов без верификации. Зарегистрируйтесь и получите скидку на комиссию!
- Подкаст выходит при поддержке Solana – быстрого блокчейна без шардинга. Подробности на solana.com и в телеграме @solanarus.
Поддержите подкаст!
- Bitcoin: bc1qec856uhwuguhnn28r54tlkrh3dh95ctajvpjaf
- Patreon: https://www.patreon.com/basicblockradio/overview
(00:00:00)
Иван Иваницкий: Привет, друзья. Это подкаст Базовый Блок. С вами Иван Иваницкий, и в гостях у нас сегодня Сергей Тихомиров. Привет, Сергей.
Сергей Тихомиров: Привет.
Иван Иваницкий: Сергей нам расскажет про конференцию MIT Bitcoin Expo, которую он виртуально посетил. Но перед этим, мы, как всегда, скажем спасибо тем, кто нас поддерживает.
Сергей Тихомиров: Да, я хочу сказать спасибо тем, кто нас поддерживает. Я тут в роли и гостя, и ведущего.
Мы хотим сказать спасибо, в первую очередь, конечно, нашим патронам замечательным, которые на patreon.com/basicbloсkradio нам кидают монетки. Эти монетки нам помогают с выпусками, с техническими всякими вещами. Спасибо вам огромное, ребята. Мы вот для вас, например, сделали бонусный выпуск 119B, где обсудили еще несколько интересных докладов с другой конференции в MIT CryptoEconomic Systems. Так что, если вы подпишетесь на Патреон, то вас там ждет уникальный контент, которого в открытом доступе нет.
А так же, мы, конечно, говорим спасибо нашим прекрасным спонсорам. Спонсоры у нас следующие: у нас есть Zerion — это простой и приятный интерфейс к миру DeFi, DeFi — это магистральное направление развития эфириум-экосистемы и Zerion здесь очень важный игрок и, как мне кажется, они делают очень крутую штуку. И ведущие Базового Блока пользуются Zerion с успехом и удовольствием, и всем его рекомендуют. Все ваши DeFi нужды, там будут удовлетворены.
Solana нас поддерживает. Solana — это очень быстрый блокчейн без шардинга, 60 тысяч транзакций в секунду. И протокол proof of history, который это все обеспечивает. Токен уже торгуется, проект поддерживает русскоязычное коммьюнити, отвечает на все вопросы на сайте, и в Телеграмме, и Вк Solanarus. Так что, участвуйте в их tour de SOL, зарабатывайте там токены и следите за ними.
И HodlHodl — наш спонсор, который нас поддерживает очень давно. Это самый быстрый, безопасный и дешевый способ купить и продать биткоины без верификации. У нас есть специальная ссылка в описании, если вы зарегистрируетесь по ней, то вы будете получать постоянную скидку на торговую комиссию. И так же, мы хотим напомнить, что совсем недавно HodlHodl представил новый дизайн торговой платформы, а также выпустил свой полноценно функционирующий API, благодаря которому HodlHodl интегрируется с биткоин кошельком BlueWallet, а по окончании интеграции, в мае, HodlHodl станет первой некастодиальной торговой платформой, доступной через мобильное приложение. Также платформа планирует новые интеграции и с другими кошельками. Редизайн платформы продолжается, и, на следующей неделе, HodlHodl обещает представить вторую часть редизайна. То есть, когда этот выпуск выйдет уже вы, вероятно, в эти примерно дни сможете новую ступень редизайна HodlHodl’a. Спасибо большое нашим спонсорам.
Иван Иваницкий: Да, пожалуй, стоит еще объявить о том, что мы с Сергеем сходили в гости к Форклогу, и эту запись можно послушать, посмотреть на их Ютуб канале, ну или у нас в Телеграмм канале, мы тоже кидали ссылочки. Так что заходите, слушайте, это теперь наши друзья. Что ж, Сергей, перейдем к нашей основной теме — это конференция. Прежде чем, ты расскажешь, о чем там говорили, опиши, что это вообще за конференция, какие в целом темы она освещает, и главное, наверное, откуда ты про нее узнал, откуда вообще узнают про такие ивенты?
Сергей Тихомиров: Ну, конференция называется MIT Bitcoin Expo. Она, как видно из названия, проходит MIT — Массачусетском Технологическом Институте, одном из топовых университетов вообще в мире. И я даже не помню, как я о ней узнал на самом деле. Эта конференция уже очень давно существует, уже, наверное, лет 8 что ли. Проводится в MIT, MIT давно и активно участвует в биткоин-экосистеме и в блокчейн-экосистеме и, да, вот у нас, собственно, третий выпуск подряд, если с учетом бонуса. То это уже третий, посвященный конференциям.
В этот раз, в начале марта у них прошло две конференции одновременно. Crypt Economic Systems, о которой мы рассказывали в 119 выпуске и MIT Bitcoin Expo, о которой мы поговорим сейчас, в 120 выпуске. Опять таки, как тоже видно из названия, основной темой этой конференции является биткоин. Она довольно техническая, она не сказал бы, что академическая, то есть, там в основном доклады, не основанные на каких-то научных работах, а скорее туда приходят разработчики, которые работают над протоколами, над какими-нибудь усовершенствованиями в биткоине и в lightning. И они рассказывают про свою работу, скажем так, не углубляясь совсем в глубокие детали, но при этом достаточно детально. То есть, если вы, допустим, разработчик и вы хотите поучаствовать в разработке биткоина, и вы ищете для себя какую-нибудь конкретную задачу, куда приложить свои усилия и какие… Ну какие сейчас задачи решает биткоин-разработчики? Вот, посмотрев доклады этой конференции, которые доступны на Ютубе в виде плейлиста, там все можно посмотреть. Можете составить представление о том, на чем сейчас работают в биткоине и, может быть, в какой-то из этих проектов влиться и приложить свои усилия.
Иван Иваницкий: Да, эта конференция, она проходила онлайн. В смысле, проходила она физически, но ты там был онлайн и, как я понимаю, большая часть слушателей тоже.
Сергей Тихомиров: Да, количество слушателей сложно оценить. Они успели в очень какое-то узкое окно.
(00:05:02)
Ну, точнее, это был, видимо, один из последних ивентов, одна из последних конференций, проведенная в реальном мире, до всякого коронавируса. Некоторые из докладчиков выступали в виде презентации удаленно, и по Зуму, и по каким-то другим средствам связи. В принципе, это было не так ужасно, как можно было ожидать, то есть, вполне можно смотреть. Не всегда был хороший звук, но если звук хороший, то, в принципе, большой разницы между живым докладом и видео-докладом со слайдами, в общем-то, даже и нет. Вот, а судя по кадрам из зала, действительно было живых посетителей немного. Наверное, из тех, кто планировал приехать, решили все-таки поберечь себя и окружающих, посмотреть это в трансляции и записи. Но, тем не менее, конференция в любом случае достойна нашего внимания, поскольку на многие интересные и актуальные темы биткоин-разработки там поднимались, и мы, я думаю, их сегодня осветим, как можем.
Иван Иваницкий: Ну, давай тогда к ним перейдем. Я смотрю, ты выделил несколько докладов наиболее интересных, давай начнем с первого из них. Это Taproot by Poelstra. Я не знаю этого разработчика, может, ты знаешь?
Сергей Тихомиров: Да, это Эндрю Поэлстра, это математик и биткоин-разработчик, который давно, опять-таки участвует в биткоине. Сейчас он работает в компании BlockStream и там участвует активно в разработке и усовершенствовании биткоин-протокола на таком, на глубоком криптографическом уровне. Тут надо сказать такой общий дисклеймер, что вот те темы, которые мы будем освещать, я совершенно не могу сказать про себя, что я их понял до конца, что я понимаю все детали, я только уловил какую-то общую идею, как мне кажется. И хочу со слушателями этим поделится, этим пониманием, но конечно там, в чате, в наших комментариях и так далее, приходите, поправляйте, дополняйте то, что я понял, давайте вместе разбираться. Потому что темы, ну, не тривиальные, довольно сложные и хотелось бы какое-то общее понимание получить. Как раз для этого, есть конференция, чтобы мог прийти человек, который понимает там очень глубоко эту тему, и он ее представляет за 20-30 минут, так, что люди, которые может быть, не так глубоко погружены, они хотя бы могут общую идею уловить.
Иван Иваницкий: Да, и следующим звеном есть подкаст, в котором мы пересказываем на еще более высоком уровне абстракции, что же происходило на конференции. Что ж, что же происходило на конференции, о чем рассказал нам Эндрю?
Сергей Тихомиров: Он сделал доклад про Taproot. Taproot — это такое изменение в биткоине планируемое, которое очень долго уже планируется, и которое планируется внедрять уже с подписями Шнорра, насколько я понимаю, в одном софт-форке. Вероятно, это произойдет в 2020 году, но конечно биткоин не может давать никаких гарантий на сроки и люди там не торопятся.
В конце 2019 года, был такой интересный очень процесс BIP Шнорр Ревью, где собирали добровольцев, которые могли бы со всего мира поучаствовать в ревью, поучаствовать в том, чтобы прочитать этот BIP, задать вопросы, какие-то получить уточнения, возможно, внести какие-то изменения в него. И там поучаствовало несколько десятков, мне кажется, человек, как минимум. На старте, мне кажется, было даже больше ста человек. Но вот Эндрю Поэлстра сделал такой обзорный доклад, и у меня, на самом деле, в голове, мне кажется, получше уложилась идея Taproot’а, чем я ее раньше понимал. Здесь надо сказать, что эта идея витала в биткоин-тусовке еще очень давно, как опять-таки, докладчик говорит еще с 2011-2012 года, на Bitcointalk обсуждалась идея, которая так же известна под аббревиатурой MAST — Merklized Abstract Syntax Trees, мерклизованные абстрактные синтаксические деревья. И главная идея заключается в следующем, точнее, вот есть некоторая неэффективность, есть некоторая… Да, неэффективность текущей конструкции биткоин-скриптов, которую дальше MAST и Taproot, в каком-то смысле имплементация пытается исправить. А неэффективность заключается в следующем, что, когда у нас есть в биткоине адрес, адрес у нас получается из хэша скрипта, который нужно удовлетворить, чтобы потратить биткоины. То есть, если я Ивану посылаю биткоины, я что фактически делаю? Иван мне дает свой адрес, я генерирую локально скрипт, который говорит, кто предъявит публичный ключ, который хэшируется в этот адрес. Во-первых, и, во-вторых, кто предъявит подпись, которая соответствует вот этому публичному ключу, тот сможет забрать эти биткоины. Я это все собираю в скрипт, хэширую это в свою очередь и помещаю это на блокчейн. Здесь есть плюсы и минусы.
Собственно, да, вот здесь тонкость заключается в том, что публичный ключ и адрес — это не одно и то же. И, когда биткоин объясняют новичкам, говорят: “У вас есть пара ключей приватные, вы им тратите, а публичный — это ваш адрес”. И на первом уровне приближения — это нормально, и не нужно здесь действительно уходить в детали. Но если вы хотите заниматься биткоин-разработкой, то вам полезно понимать, что публичный ключ — это публичный ключ.
(00:10:01)
Это криптографическая структура. А адрес — это некоторая структура, ну, некоторая строка в биткоин-протоколе, которая получается из хэша публичного ключа. То есть на блокчейне, если, опять-таки, я отправил биткоины на адрес Ивана, то блокчейн на самом деле не знает, какой публичный ключ подойдет, чтобы эти биткоины разлочить и потратить. И теперь, когда Иван захочет потратить эти биткоины, его кошелек предоставит транзакцию, которая будет содержать в себе публичный ключ и подпись. То есть, для того, чтобы потратить биткоин с какого-то адреса, я говорю, окей, вот мой публичный ключ или, если более широко говорить, вот скрипт, который я хочу удовлетворить, а вот параметры, которыми я его удовлетворяю. То есть, если, например, это просто платеж на адрес, то Иван говорит, вот мой публичный ключ и вот моя подпись. И дальше биткоин-core проверяет, что, окей, во-первых, публичный код хэшируется действительно в этот адрес, а во-вторых, подпись соответствует публичному ключу.
Ну, как бы long story short, в чем здесь собственно, плюсы и минусы. Плюсы в том, что по блокчейну нельзя понять структуру скрипта, ну или необязательно ее можно понять, которая содержится в данном адресе. Это становится очевидным, это становится доступной информацией только в тот момент, когда биткоины тратятся. То есть, я хочу потратить биткоины, я предъявляю свой публичный ключ. Да, конечно, есть здесь элемент безопасности, я еще не сказал, собственно, ради чего городить огород, и почему просто не сделать адрес закодированным публичным ключом. Насколько я понимаю, это связано с безопасностью, и это связано, наверное, это связано с квантовыми компьютерами, которые потенциально могут взламывать подписи и потенциально могут находить приватные ключи к публичным ключам. Хэш-функции они все-таки не могут взламывать, насколько я понимаю. То есть, у нас есть такой дополнительный уровень защиты, даже если будет квантовый компьютер или какой-то другой способ взламывать подписи, все равно, мои биткоины с блокчейна нельзя будет украсть, потому что публичный ключ неизвестен. Он скрыт за хэшем. Вот. Но получается здесь следующая неэффективность. Казалось бы, зачем… Да, вот, у нас есть скрипты, как известно. В биткоине. И они могут кодировать более сложные вещи, чем просто вот такая-то подпись соответствует публичному ключу. Мы можем изобрести какой-нибудь мультисиг, например. Там два из трех. Мы можем навесить на это тайм-локи. Мы можем какие-нибудь хэш-локи на это навесить, как в lightning например, делают. И прикол в том, что, когда я хочу потратить транзакцию с какой-то сложной структурой, я должен удовлетворить условия только в одной ветке этого смарт-контракта, но при этом, я должен предъявить целиком его код. То есть, я говорю вот целиком весь код этого смарт-контракта, вот весь скрипт, а дальше, я удовлетворяю эту конкретную ветку, вот этими конкретными аргументами. И спрашивается, вот зачем? То есть, получается, что у нас все полные узлы в биткоине, вот мы с тобой закодировали, например хитрый смарт-контракт с десятью вариантами, как его можно исполнить. Там или такая комбинация ключей, или сякая комбинация ключей. И потратить эти биткоины, можно будет только одним способом, каким-либо из этих десяти способов. Но, тем не менее, тот кто это будет тратить, должен будет все эти десять способов положить в транзакцию, ее забродкастить, все они должны иметь право лидировать, и все они должны будут хранить еще навечно. Вот, спрашивается, зачем же нам так делать неэффективно.
Иван Иваницкий: Я начинал смотреть этот доклад, и у меня к докладчику возник вопрос, что это вообще за юз-кейс, в котором мы… Ну, понятно, что он бывает, но выглядит, как будто бы это не очень распространенная штука, в котором мы позволяем монеты с одного и того же адреса тратить многими разными способами? А, слушай, ну или тот же мультисиг – это, по сути, и есть возможность потратить монеты разными способами, да.
Сергей Тихомиров: Да, да, здесь у нас будет мультисиг. Мультисиг — это некоторый адрес, за которым скрывается сложный скрипт. В блокчейне ты видишь только адрес, и адрес, ну, стандартную имеет форму. Но дальше, когда кто-то его тратит, он говорит, вот мультисиг, он закодирован, у него условия два из трех. Вот эти три возможных ключа, а вот я даю вам два ключа, вот первый и второй. То есть информации на самом деле больше, чем, необходимо технически.
Иван Иваницкий: Да, больше, чем нужно. То есть, он раскрывает не только свой публичный ключ, как минимум, но еще и два других, ну вот, в этом примере.
Сергей Тихомиров: Да, и он раскрывает, более того, он раскрывает структуру собственно. То есть, я не могу потратить мультисиг, не раскрыв всему миру, что это был мультисиг, что тоже, в некотором смысле нарушает приватность наших договоренностей. И дальше возникла такая идея, которая называлась изначально MAST, про то, что было бы классно сделать такую конструкцию внутри этой скриптовой машины, которая бы не требовала того, чтобы тот, кто тратит биткоины, весь скрипт целиком клал на блокчейн.
(00:15:09)
А именно, появилась идея закодировать условия траты биткоинов в виде дерева меркла, и только его корневой хэш использовать в транзакции, который тратит биткоин. То есть, вместо того, чтобы говорить, вот целиком скрипт, я его трачу таким-то способом, я говорю, примерно, следующее, вот есть какой-то скрипт, у него есть такой-то меркл-хэш, мерклрут-хэш, и вот конкретные условия, которыми я хочу удовлетворить. Я доказываю две вещи. Во-первых, что это условие входит в это дерево где-то. И, во-вторых, что я действительно могу удовлетворить этому условию. То есть, в случае с мультисигом, я могу сказать, что вот, мы можем… Так сходу не придумывается, но если у нас есть, допустим, не знаю, 8 разных условий, которыми мы можем потратить биткоины, мы их кодируем в виде дерева, глубиной на три уровня. Я доказываю, что вот это условие — это один из листочков, и, вот действительно, он хэшируется в корневой хэш. И, во-вторых, что у меня есть подпись, которая удовлетворяет этому кусочку, этому листочку. Мы, таким образом, не раскрываем информацию о том, а что было в других листах, что снимает проблему, описанную выше.
Иван Иваницкий: Знаешь, какую структуру мне это напомнило? В похожей парадигме строится ZK rollup. Такой подход к масштабированию эфира, в рамках которого мы кладем на основной блокчейн, грубо говоря, хэши вот меркл-рутов как раз. И балансы мы поддерживаем в листьях этого MerkleTree. И смарт-контракт у нас только проверяет Zero Knowledge доказательство того, что все переходы от предыдущего дерева к нынешнему были корректными.
Сергей Тихомиров: Да, в каком-то смысле такая идея, ну, довольно обобщенная. То есть, что мы можем для того, чтобы проверить какое-то условие, необязательно предоставлять всевозможные варианты, а нам достаточно доказать, что то, что мы хотим доказать, в каком-то смысле входит в более большую структуру, в какой-то общий стейт. Но в эфире, у меня это в каком-то смысле проще реализовать, потому что там есть стейт, как таковой, а в биткоине, как такового стейта нет. Поэтому, нужно изобретать какие-то новые опкоды, чтобы это можно было реализовать.
Иван Иваницкий: Да, я вот, собственно, почему об этом подумал, в свое время, когда я узнал про этот ZK rollup, я удивился, потому что я до этого момента думал, что Zero Knowledge, это что-то в первую очередь, скорее для приватности. А вот в этом случае, он используется для масштабируемости. И в контексте Taproot’а, у меня тоже возник вопрос, а в чем основная мысль? В том, чтобы достигнуть приватности? То есть, скрыть остальные данные, остальные способы потратить этот выход, раскрывая только тот способ, который мы его в итоге тратим. Или же это шаг в сторону масштабируемости, то есть, условно, если нам не нужно в блокчейн класть все эти способы, то мы экономим место просто на блокчейне. Если там, в рамках доклада, был ответ на этот вопрос, то будет круто его от тебя услышать.
Сергей Тихомиров: Ну, я возможно уже подзабыл детали. Их тех заметок, которые я записал, не вижу такого прямого ответа, но мое понимание заключается в том, что это придумано, скорее, во-первых, для приватности, а во-вторых, для масштабируемости. Но не в том смысле, что у нас будет больше транзакций в блоке, потому что это не про то. А, скорее, про то, что каждая транзакция может иметь более сложную внутреннюю структуру. То есть, если у нас сейчас те же самые мультисиги, я не помню какое там ограничение точно, но просто, исходя из размера транзакции и размера блока, не можешь сделать мультисиг, не знаю, 500 ключей из 700. Ну что-нибудь такое, да. Это просто не поместится никуда. Мультисиг, это максимум там 3 из 5, 5 из 7, там вот такого порядка величины. А если у нас есть конструкция, где мы можем это дерево Меркла запихивать, можем сделать мультисиг, не знаю, 533 из 1035 ключей. И ты эти 1000 условий закодируешь, у тебя будет дерево, глубиной 10, ну наверное, 10 этих хэшей поместится, наверное у нас в транзакцию. Я немножко фантазирую, но понимаешь, да, если мы можем, если у нас есть там Х слотов в транзакци, раньше мы могли закодировать, как бы, некоторую линейную комбинацию от Х вариантов, а теперь мы можем эти Х слотов превратить в логарифм. То есть, мы можем дерево, глубиной Х, составить из разных вариантов. Что расширяет астрономически количество возможных комбинаций, ключей, хэш-локов, тайм-локов и чего захотим.
Иван Иваницкий: Ну, если я правильно понимаю, на первый кейс масштабируемости, который ты упомянул, это тоже должно влиять? То есть, если раньше у нас там такой-то скрипт, мы его должны были класть целиком.
(00:20:00)
И, условно, таких скриптов у нас влезало 100 штук. То теперь, мы можем его класть не целиком, а только его часть и хэши остальных частей. И таких же скриптов у нас влезет тогда больше.
Сергей Тихомиров: Наверное. Я здесь не готов прямо с цифрами в руках отвечать. Наверняка, это кто-то посчитал, но здесь тоже, как бы, это не дается бесплатно. Ведь для того, чтобы сделать доказательство, что у нас что-то зашло в меркл-дерево… Кстати, про это мы сейчас дальше поговорим. У меня есть заметки. Я начал некоторый аргумент, но глядя на свои заметки, я понимаю, что он как бы… Этот вопрос снимается дальше криптографией. Вот смотри, вопрос, который возникает дальше. Окей, мы сделали дерево с 1000 листьев. Оно будет у нас глубиной 10. И, то есть, получается, что все равно нужно будет 10 хэшей класть на блокчейн. И так ли это, ну это тоже довольно много. То есть, все равно казалось бы, мы глубокие деревья не сможем запихнуть в одну транзакцию. Но здесь, насколько я опять-таки понял из доклада, нам приходит на помощь криптография. И именно, почему Taproot и Шнорр являются частью одного апдейта, потому что для правильной реализации Taproot’а, Шнорр необходим. Шнорр — это такие хитрые подписи, которые умеют элегантно комбинироваться, и, в частности, они допускают, насколько я опять-таки понял, кодирование некоторой дополнительной информации внутри самой подписи. Это несколько рифмуется с ранней идеей, которую высказывал тот же Эндрю Поэлстра на предыдущих конференциях. В году ещё 2017, кажется. И возможно, наверное, вот это является реализацией этой идеи, более современной ее реинкарнацией. Та идея называлась scriptless scripts, то есть, скрипты без скриптов. И идея была в том, что у нас могут некоторые условия кодироваться прямо в самой подписи. То есть, с точки зрения стороннего наблюдателя, это просто какая-то криптографическая операция, такая же, как и любая другая. То есть, просто какие-то рандомные величины, вот это подпись, вот это ключ, и там, все сходится, либо не сходится. А на самом деле, если ты знаешь какой-то секрет или какую-то дополнительную информацию, ты можешь из этого ключа извлечь еще дополнительные… Ну, дополнительную информацию о том, что какое-то еще условие, помимо того, что подпись валидна, удовлетворено или нет. И, насколько я понимаю, идея вот этой связки Taproot’а и Шнорра в том, что корень дерева-меркла, в котором собираются все условия, кодируется внутри некоторого коммитмента и внутри, как бы, самой подписи по алгоритму Шнорра. Вот, это мое понимание. Я здесь не настолько криптограф, так что вряд ли я смогу более подробно это объяснить, но, там, идеи я думаю более или менее понятны. Значит, мы кодируем без дополнительных байтов, мы кодируем этот коммитмент внутри самой подписи.
Иван Иваницкий: Слушай, я еще хотел уточнить, правильно ли я понимаю, как у нас происходит экономия места в случае использования этих MAST’ов, то есть, мы берем, условно, у нас есть 8 условий, мы удовлетворяем одному из них, представляем лист. Для того условия, с которым оно хэшируется, чтобы попасть на следующий более высокий уровень дерева, мы не предоставляем самого условия, мы предоставляем только хэш. Поднимаемся на одну ветку вверх, не предоставляем те соседних два условия, а предоставляем хэш уже их ветки. Их двух хэшей ветки делаем еще один хэш и предоставляем еще один хэш. То есть, в итоге мы предоставили раз, два, три, четыре кусочка данных грубо говоря, вместо восьми.
Сергей Тихомиров: Да, да. То есть, мы предоставляем, ну, в стандартном сценарии, мы предоставляем, собственно, сам лист. То есть, те данные, которые мы хотим доказать, что входит куда-то, плюс, то количество хэшей, которое соответствует глубине дерева. То есть, сколько нам нужно сделать шагов до верха, до корня, столько мы и предоставляем. Вот дальше, у меня немножко плывет мое понимание, насколько этот процесс, как бы, какие именно части этого процесса, оптимизируются за счет криптографии, за счет подписей Шнорра? Но вот дальше у меня записана следующая фраза, что можно будет hide Merkle root in key commitment. Понимайте это как хотите. Ну, то есть, общая идея в том, что есть хитрая криптография именно подписи Шнорра, которая позволяет процесс меркелизации условий трат скриптов оптимизировать. Именно поэтому. она хорошо сочетается вот с самой идеей меркализации и абстрактных синтаксических деревьев. Вот. Есть еще третий аспект этого апдейта. Ну, он немножко, для меня, честно сказать, выглядит немножко не элегантно что-ли. То есть, это некоторый ну костыль, не костыль, какое-то условие, которое не очень хорошо вписывается в общую картину. А именно идея такая, что если у нас в этой конструкции с Taproot’ом участвуют несколько ключей, то предлагаемый опкод в биткоине, будет разрешать тратить эти биткоины, не обращая внимания вообще на дерево, если все ключи, которые туда входят, подписывает мультисиг.
(00:25:10)
То есть, если мы делаем мультисиг на пятерых человек или на восемь, с какими-то ещё условиями, и мы все эти условия заворачиваем в дерево, то хорошо. Можем потратить одним из нескольких вариантов, который в дереве, но плюс ещё у этого дерева, как бы есть сбоку веточка такая специальная, если все подпишут, что они согласны, тогда мы тоже можем потратить. И это как бы такая оптимизация, потому что в этом случае нам вообще, вроде как, не нужно будет лезть в дерево. То есть, не нужно будет этот меркл-процесс доказывать. И считается, что поскольку скрипт кодирует некоторый контракт между какими-то участниками, которые соответствуют ключам, то если все участники согласны, то почему бы нам не потратить биткоины, действительно, если все согласны.
Иван Иваницкий: Да, звучит логично. Я хотел задать вопрос, а почему это просто не сделать еще одним… Одной веткой в этом дереве, то есть такое условие, что, окей, мы можем потратить 3 из 5, если у нас настал какой-то момент времени, то есть плюс тайм-лок. Либо мы можем потратить, при наличии 5 из 5 подписей, но ты, в общем-то, на этот вопрос уже ответил, что нам не нужно лезть в саму структуру дерева тогда.
Сергей Тихомиров: Да, но в каком-то смысле это и есть еще один лист дерева, вот только он by construction, находится на глубине 1. То есть, видимо предположение заключается в том, что на базе этой штуковины будут строить новые протоколы второго уровня, такие как лайтнинг. Или, может быть, в лайтнинг это пронесут и как-то оптимизируют лайтнинг. И предполагается, что большинство сценариев траты будут хорошими. То есть, если все согласились, все потратят какой-то новый стейт, и большая часть реальных трат будет с согласия всех сторон, если мы это оптимизируем, то мы таким образом сохраним больше места в блокчейне. А на случай, если мы будем более сложные условия использовать, тогда у нас есть этот механизм с деревом.
Иван Иваницкий: Да, звучит интересно. Но нужно смотреть, что on top of this можно будет построить, вернее что построят. А правильно ли я понимаю, что таким образом мы обсудили все основные аспекты этого доклада?
Сергей Тихомиров: Да. Я советую его посмотреть, он не такой длинный, вообще все доклады не очень длинные. Мне кажется, они укладываются в пол часа обычно. И это такой оптимальный, мне кажется, формат временной, чтобы донести основную идею, но не углубляться в совсем уж тонкие детали. Я думаю, что я как мог это более или менее донес до аудитории, давай, наверное, пойдем дальше.
Иван Иваницкий: Смотри, я в этом докладе еще помню такой момент, не знаю сможешь ты его прояснить или нет, но упомянуть о нем точно стоит. Докладчик сказал, что сама идея этих MAST’ов, она возникла достаточно давно в 2011-2012 году. Но не было возможности, их как следует имплементировать, потому что сам процесс принятия изменений в биткоине довольно сложный, а сейчас такая возможность появилась, потому что, за это время, немножко разобрались, как работать с софт-форками, хард-форками, как вносить изменения так, чтобы меньше затрагивать другие части. Вот понял ли ты, что конкретно он имеет в виду, то есть можешь ли ты как-то конкретизировать эти слова?
Сергей Тихомиров: Я могу их конкретизировать только в небольшой степени. Что я про это знаю, это что вместе с сегвитом в 2017 году был внедрен механизм изменения протокола софт-форками, которые более аккуратны, чем это было принято раньше, то есть там теперь есть в блоках некоторый version bit, который отражает версию протокола, которую этот клиент поддерживает, этот full node поддерживает, и стало в каком-то смысле проще или, по крайней мере, понятнее как именно выкатывать софт-форки. Я, к сожалению тут больше, наверное, не могу сказать. Это такие штуки, связанные с сигнализированием, как выкатывали segwit. То есть, там должны были майнеры просигнализировать, что они поддерживают с помощью этого version bit’а. То есть, там какая-то теперь уже более или менее streamlined, более или менее точный механизм выкатывания изменений и теперь это не является чем-то таким из ряда вон выходящим, типа мы выкатываем софт-форк и, значит, молимся, чтобы ни у кого ничего не упало. Теперь это более какой-то понятный процесс, но я больше подробностей, наверное, не смогу предоставить.
Иван Иваницкий: Мы с тобой в лучших традициях Базового Блока сделали почти идеальный переход к следующей части, потому что следующий доклад называется Contributing to Bitcoin Core — Внесение изменений в bitcoin-core Джеймса О’Бирна, ресерчера из Digilab, и расскажи нам о чём он был.
Сергей Тихомиров: Ну этот доклад на самом деле состоит из двух частей, и одна часть про то, как вообще устроена разработка Bitcoin Core, и как в ней разработчикам можно поучаствовать. А вторая часть про, собственно, проект, который этот разработчик, Джеймс О’Бирн тащит и продвигает.
(00:30:04)
Который, насколько я понимаю, не то чтобы близок к внедрению, но уже определенная работа проделана. На самом деле, у меня мало осталось заметок именно про первую часть, потому что никаких особо сюрпризов там не было. То есть, он рассказал вот все эти вещи, которые я думаю, многие слушатели знают, про то, что bitcoin-core — очень консервативная штука, что там разработка ведется медленно, это специально так сделано, что там довольно строгий процесс peer-ревью и строгий формализованный процесс внесения изменений. Которые предполагают, что в начале люди пишут Bitcoin Improvement proposal (предложения по улучшению -прим.), точнее даже так, с самого начала, когда появляется только идея такая неоформленная, её принято обсуждать в mailing-листе, в каких-то в чатах irc, по каким-то ещё не совсем формальным каналам. Когда feedback собран, и более или менее идея кристаллизовалась, по крайней мере в голове ее создателя, он пишет Bitcoin Improvement proposal, и тоже над этим документом ведется работа, чтобы было четкое описание того, что мы собственно хотим сделать, почему это важно и так далее. А потом идет имплементация, которая тоже может длиться месяцами и годами. То есть, это вот процесс, которым внедряли все последние изменения биткоина, вот докладчик, как человек который в этом участвует непосредственно, он описал, что вас может ждать как разработчика, не ждите, что ваши изменения примут там через неделю. Ждите долгих въедливых дискуссий со старожилами, которые это все делают для нашего общего блага, чтобы случайно в bitcoin-core не пролез какой-то баг или другой нежелательный код.
А если говорить именно про проект, который Джеймс имплементирует, то проект этот называется Assume UTXO. И главная цель, которую он ставит — это оптимизировать процесс начальной загрузки блоков, или по английски аббревиатура Initial Blockchain Download или IBD. Проблема была в том, что начальная загрузка блоков — это долго. И гипотеза состоит в том, что довольно много пользователей были бы, в принципе готовы у себя держать полную ноду, пусть она там даже занимает 200 с чем-то гигабайт, это может быть даже не такая большая проблема, учитывая, что на Bitcoin-core позволяет старые блоки выкидывать. То есть, я могу синхронизироваться с самого начала, валидировать все блоки, я сам убеждаюсь, что все валидно, но просто старые данные я выкидываю, потому что они мне уже не нужны, я их проверил, я как бы себе доверяю, я их выкидываю. То есть в принципе, не такие уж и большие системные требование на то, чтобы поддерживать Bitcoin-core ноду у себя, за исключением времени на начальную загрузку. То есть, эти 280, по-моему, гигабайт, их нужно все таки выкачать из сети и провалидировать. Это долго. И для того, чтобы этот процесс сделать быстрее, предлагается сделать следующее. Предлагается некоторый чит сделать, заключается который в следующем, собственно, в чем конечная цель, в результате этого Initial Blockchain Download, я к чему хочу прийти? Я хочу прийти к тому, чтобы у меня был текущий snapshot UTXO, чтобы я понимал, у кого сколько биткоинов, то есть на каких адресах, какие непотраченные UTXO лежат. И в принципе, казалось бы, я же могу этот UTXO сет просто у кого-то взять. То есть, допустим, Вань, допустим у тебя есть полная нода синхронизированная. Было бы классно, если бы ты мог из нее вытянуть этот UTXO сет, он занимает несколько гигабайт, там 3 или 4. Мне его переслать, и, чтобы я мог запустить свою ноду уже на готовом этом UTXO сете. А потом, то есть, я запускаю ноду. То есть, предполагается, значит, что происходит, я откуда-то скачиваю 3 гигабайта текущего UTXO сета, я запускаю свою полную ноду с этим UTXO сетом, и нода уже начинает работать, но параллельно, в бэкграунде, она начинает синхронизироваться по-правильному, то есть прям вот с генезиса прокручивать. И интересно, что у меня есть некоторый вот начальный период, в течение которого, возможно, у меня гарантия безопасности не настолько сильная, как при полной синхронизации. То есть, я могу, например, на текущий UTXO сет провалидировать по заголовкам. То есть, проверить, что там действительно pow нормальный во всех блоках, но не проверять валидность этих блоков и не проверять сами транзакции. То есть, я в какой-то степени тебе доверяю, как источнику этих UTXO, я понимаю, что они не совсем бред, потому что они все-таки привязаны к настоящему proof of work, я уже могу своей нодой начать пользоваться. А тем временем, у меня в бэкграунде, происходит обычная синхронизация и, в какой-то момент, эти два процесса должны сойтись. То есть, тот UTXO сет, который получен, он тоже продолжает обновляться, насколько я понимаю. И тот UTXO сет, который я сам получил независимо с самого начала, они в какой-то момент, ну, второй догоняет первый, и в этот момент должна произойти сверка значений.
(00:35:01)
Если они полностью совпали, тогда все, у меня готовая нода полная. Со своим UTXO сетом. И сейчас задача состоит в том, чтобы несколько переделать исходный код Bitcoin-core, потому что в исходном коде изначально, конечно, ни у кого не было такой идеи, что может быть несколько UTXO сетов разных. То есть, это просто не реализовано было. А сейчас, вот этот proposal и пул-реквест, который его реализует, он абстрагирует функциональность, связанную с UTXO сетом. Он говорит, а у вас может быть два UTXO сета теперь. И один будет настоящий, мой собственный. А второй будет полученный откуда-то. Но дальше нужно много сделать такой технической работы, как нода будет работать там с одним или с другим, как она их будет сверять в конце. Это первый этап реализации этого протокола, потом уже следующая часть, которая планируется, когда будет первый сценарий, заработает достаточно хорошо, что можно продумать какой-нибудь механизм дистрибуции UTXO сета прямо внутри биткоин-протокола. Но это уже планы на далекое будущее. Не уверен, что это вообще, насколько это вообще разумно. Но, в принципе можно себе представить ситуацию, когда я могу постучаться по p2p какой-нибудь ноде, попросить мне дать полный snapshot UTXO, прямо не выходя из блокчейна. Ну, а в качестве альтернативного варианта могут быть какие-то дополнительные сайты, на сайте bitcoincore.org или на каком-нибудь еще сайте, размещается UTXO сет, его подписывает разработчик своим PGP-ключом, какой-нибудь известный человек. Или, я не знаю, ну там какие-нибудь разные придумывать гарантии целостности. Ты проверяешь чек-суммы, например, когда его скачиваешь, ну чего-нибудь такое, вот. Ну, дальше так используешь.
Еще докладчик рассказал про практические вещи, практические аспекты, связанные с реализацией, про то, что он вот это все имплементировал, вот, и пытался сделать правильный пул-реквест. И он говорит, что очень важно разбивать свои изменения, на как можно более мелкие коммиты, все тщательно документировать, общаться с разработчиками, описывать четко свою мотивацию, то есть, не просто там пул-реквест послать, и там какой-то код, который что-то делает. Нужно что-то подробно описать, в чем была цель, почему именно так это решено было реализовать, и вот что делает каждый кусок кода. И тогда это облегчает задачу ревьюерам и, соответсвенно, ускоряет процесс принятия этих изменений.
Иван Иваницкий: Слушай, я, может быть, не до конца понял мотивацию для внесения такого изменения. Потому что, вроде как скачать, сколько ты сказал? 280 гигабайт да? Вроде как, придется подождать, но не такая серьезная задача, для современного интернета. Понятно, что там будут некоторые ограничения, связанные с тем, что ты не с Амазоновского сервера качаешь, но тем не менее. Понятно, зачем похожую проблему решают в эфире, где просто, чтобы скачивать все, что майнят сейчас, тебе нужно иметь очень быстрый интернет и быстро это на своем компе проверять. Но вроде как в биткоине, такая проблема стоит менее остро, и, вроде как, я не очень понимаю, в каком случае тебе может потребовать запустить ноду вот прямо сейчас, безотлагательно, и ты не мог ее засетапить заранее.
Сергей Тихомиров: Я думаю, это все, так сказать, мы сейчас говорим про marginal users, то есть, понятно, что у всех пользователей есть какой-то порог тех. сложностей, которые они не готовы перейти, ради того, чтобы у них была полная нода и, есть предположение, что много людей находятся за этой гранью. Ну, я, в принципе мог бы это поднять, но оно будет, у меня комп будет работать там много часов, скачивать эти 300 гигабайт, а он там, не знаю, шумит, и мне мешает спать. И в конце концов, не у всех такой быстрый интернет. То есть, у меня, насколько я понимаю, 100-мегабитный интернет, то есть примерно, 10-12 мегабайт в секунду, то есть, он за несколько минут скачивать гигабайт, но 300 гигабайт, это несколько часов, наверное, да? То есть, это далеко не мгновенно. И это у меня очень хороший интернет. А у многих людей он маленький, слабенький, и компьютеры тоже могут быть слабенькие. И мне кажется, что правильно, что Bitcoin-core делает одной из своих целей, чтобы даже люди в каких-то удаленных районах со слабым интернетом, со слабыми компами все равно могли независимо валидировать блокчейн. Это некоторая идеология проекта — дать всем возможность независимо проверять валидность транзакций.
Иван Иваницкий: Может быть, биткоин-сообщество просто пытается хоть с какой-то стороны защититься от SJW, которая всегда готова обвинить в дискриминации и потребовать инклюзивности.
Сергей Тихомиров: Ну, все таки, такой инклюзивности, чтобы можно было полную ноду валидировать на телефоне Нокиа 1100, или какой там была самая Нокиа, которую нельзя топором порубить, да?
(00:40:07)
Но все-таки такой инклюзивности, я боюсь, мы не добьемся. Но делать это на слабеньком ноутбуке десятилетней давности, по идее, мне кажется, должно быть возможно. Может быть долго, но это должно в какое-то разумное время завершиться, этот процесс. Кстати говоря, я тут вспоминаю, в Твиттере есть один чувак, которого я читаю, давно его люблю. Эрик Уол, который пишет про биткоины, про разные альткоины. И очень в таком забавном ироническом ключе разоблачает всякие булшиты. Он писал про IOTA, он писал про… Про кого еще писал? Забыл. В общем, рекомендую. Он проводил эксперимент в прошлом году, может ли он на своем ноутбуке, синхронизировать ноду эфириума вот в самом архивном режиме, вот в самом таком хардкорном, вот прям вот, абсолютно с нуля. И он ее синхронизировал месяц. То есть, где-то через 25 дней непрерывной работы, он догнал блокчейн, причем к концу скорость этой синхронизации валидации, она была в 10 раз быстрее, чем реальное время. То есть, это совсем медленно. Вот, видимо, Bitcoin-core хочет таких проблем по возможности избежать, и как можно больше расширить круг потенциальных валидаторов.
Иван Иваницкий: Да, и задача поставить полную ноду на старый компьютер, может быть больше, чем баловством или нехваткой денег. Один мой друг — фанат серии ThinkPad. И он рассказывал, что последний компьютер из серии ThinkPad, на который можно поставить libreboot, это свободный Boot Firmware, то есть не проприетарный. А насколько я знаю, на всех компьютерах, на которых мы работаем, там даже если стоит какая-то OpenSource операционная система, то boot там все равно проприетарный. Так вот, последний синкпад, на который можно поставить libreboot — это X200. Он пока что не совсем устаревший, но время идет, и может быть кто-то захочет на полностью OpenSource комп поставить себе полную ноду. И тогда действительно, вот это вот изменение придется очень в кассу.
Сергей Тихомиров: В качестве конечной цели этого проекта, докладчик заявил, что он хочет, чтобы первоначальная загрузка блокчейна происходила в течение часа. И вот они к этому идут. И еще один совет от него, как вам действовать, если хотите прокачаться в качестве биткоин-разработчика. Он говорит, что ему кажется очень полезным общение живое. Конечно, я понимаю, что в данные коронавирусные времена это очень затруднено, но когда это все закончится, иметь в виду. Он говорит, очень полезно общаться вживую с настоящими разработчиками, которые в этом копают. И, в частности, он говорит, если есть такая возможность, если вы хотите всерьез этим заниматься, то присоединяйтесь к какой-то компании, которая ведет разработку или присоединяйтесь к residency (резиденции — прим.). Например, такая программа, которую ведет ChainCode, откуда у нас Глеб Науменко был в гостях, он про нее рассказывал в одном из наших выпусков. Это такое образовательное мероприятие, которое собирает разработчиков, которые хотят влиться в биткоин, и, в свою очередь, разработчики, которые уже там давно. Их учат и на практике руками что-то имплементировать. Вот такого рода ивенты докладчик находит очень полезными и всем рекомендует, когда это вновь будет возможно в живом режиме.
Иван Иваницкий: Ну, перейдем тогда к следующему докладу. Он у на посвящен BIP’у 119 Cheсk Template Мerify. Рассказывал Джереми Рубин. И что же он нам рассказал?
Сергей Тихомиров: Он нам рассказал про еще один BIP, который находится в относительно поздних стадиях принятия, или как это сказать, стадиях внедрения.
Иван Иваницкий: Стадиях торга, стадиях принятия.
Сергей Тихомиров: Стадиях торга, да. Да. Про этот BIP даже есть отдельный сайт, по адресу utxos.org. И он такой очень немножко, мне кажется сенсационно так звучит. Ты заходишь на этот сайт, и тебе говорят: “The Wait is Over, OP_CHECKTEMPLATEVERIFY is a simple improvement to Bitcoin which will power the next wave of adoption”. (Ожидание окончено. OP_CHECKTEMPLATEVERIFY — это просто улучшение биткойна, которое обеспечит новую волну принятия — прим.) Ты такой, когда, ICO, когда To The Moon? На самом деле, это вполне себе разумный proposal, и сейчас, я опять таки пытаюсь на уровне своего понимания, объяснить в чем он заключается. Тут тоже, в этом смысле он похож на Taproot, тем, что у него какая-то есть такая общая, общий framework (рамки -прим.) мотивации, который выстраивается вокруг него, что вот у нас есть традиционный способ, в котором работают биткоин-скрипты, вот есть некоторая в них неэффективность и некоторая вещь, которая теперь, по прошествии 10 лет, мы видим, что можно было сделать по-другому, как-то более оптимально и так далее.
(00:45:04)
Давайте мы добавим еще один опкод, еще один вариант забирать биткоины и тратить потом биткоины, который был бы, в каком-то смысле, для какого-то юзкейса более оптимальным. Здесь, Джереми Рубин, ну и, очевидно, люди, которые также участвовали в разработке этого proposal’а, они пытаются адресовать следующую неэффективность. Да, ну, давайте я попробую этот proposal вкратце описать, насколько я его понял, и он пытается следующую проблему решить. Сейчас у нас в биткоине транзакция не может создать такой выход, не может создать такой UTXO, который можно было бы потратить, каким-то ограниченным образом. То есть, если я Ивану отправляю биткоины, и Иван мне дает свой адрес, я составляю скрипт, кладу его в блокчейн, и говорю, кто предъявит подпись вот к такому-то адресу, тот сможет эти биткоины отправить куда угодно. И вопрос в том, нельзя ли нам сделать какую-то дополнительную конструкцию, которая бы позволила мне в моей транзакции, уточнить, куда Иван потом сможет потратить его биткоины.
Иван Иваницкий: Я в связи с этим подумал, сможет ли Бог создать такой UTXO, который не сможет потратить.
Сергей Тихомиров: Ну, он смотрит видимо просто форкнуть блокчейн. И тогда создать любой стейт. Но да, тут немножко да, надо сказать, что этот proposal, эту конструкцию я, наверное, понял хуже, чем остальные, поэтому я могу здесь немножко плыть, но общая идея такая. Вот, например, usecase, который докладчик рассмотрел, почему это может быть полезно? Это так называемые vaults, так называемые сейфы. Это не те vaults, которые хранятся в MakerDAO, и могут пропасть, если курс эфира упадет на 20%. А это такие vaults, в которых действительно, как в сейфе, хранятся ваши сбережения на пенсию, под мега секьюрными замками. В чем проблема vaults, и вообще с долгосрочным хранением биткоинов? Проблема в том, что если ваш ключ утек все таки, ваш самый главный холодный ключ из холодного хранилища утек, то вы уже ничего не сможете поделать, никак не сможете спасти свои биткоины. У вас злоумышленник их уносит и все. Хотелось бы, чтобы было некоторое промежуточное состояние. Такое, что если вы видите, что ваши биткоины из холодного хранилища начали куда-то двигаться на какой-то другой адрес, а вы при этом эту транзакцию не авторизовали, чтобы вы могли достать еще другой ключ, и из этого промежуточного хранилища перевести эти биткоины обратно себе. То есть, пока, казалось бы, ничего необычного, то есть, мы вполне можем делать тайм-локи, да, сделать в транзакции два пути исполнения, либо, если до тайм-лока, то вот такой ключ можно потратить, если после тайм-лока, то другой ключ можно потратить, но идея состоит в том, что я хочу формат этой транзакции специфицировать, еще когда я кладу монеты, в хранилище. То есть, я хочу создать такую транзакцию, которая говорит, положи мои монеты в хранилище, а потратить можно будет их только одним из двух способов.
И в этом принципиальная разница, то есть, как нам поясняет докладчик, что этот proposal позволяет разделить, как он формулирует “concern of receiving and spending”. То есть, сейчас у нас в современных биткоин-транзакциях, условия фактической траты биткоинов и получения биткоинов слеплены в один процесс. Если я отправляю Ивану биткоины, факт того, что он их забирает, это одно и то же событие, что и я их отправляю. То есть, это просто одно событие, одно и тоже. А в этом proposal’е можно будет сделать так. Я биткоины Ивану отправляю, и они находятся на некотором буферном адресе. Иван их еще не забрал, но при этом, этот буферный адрес устроен таким образом, что мы все понимаем, что только Иван их сможет забрать. Например, после какого-то времени, или при каких-то еще дополнительных условиях. Это полезно для холодных хранилищ, как я это описал. Это еще может быть полезно для каналов. Но здесь я больше, честно говоря, не могу объяснить, почему это полезно для каналов. А дальше, это полезно для оптимизации транзакций, которые биржа отправляет. чтобы нескольким сразу клиентам выдать биткоины, то есть, да еще вот, когда…
Иван Иваницкий: Слушай, позволь, я еще раз для себя проговорю механизм, чтобы понять, правильно ли я тебя понял? То есть, до этого, до этого proposal’а, мы можем накладывать какие-то условия на то, чтобы человек мог потратить эти UTXO или не мог. Но если эти условия удовлетворены, то есть там, например, прошел тайм-лок и он предоставил подпись, то он может его тратить как угодно?
(00:50:00)
А в этом proposal’е, мы хотим сделать так, чтобы он его мог тратить не как угодно, а на то и как он его будет тратить, было наложено какое-то условие. То ли через какое-то время, то ли на какие-то определенные адреса?
Сергей Тихомиров: Да, да. Именно так. Здесь еще, кстати говоря, если сравнить с тем же эфириумом, и почему у нас в эфириуме есть больше разнообразия, разных смарт-контрактов и большее количество юз-кейсов. Именно потому, что у нас там легко можно реализовать такую семантику, то есть какие-нибудь токены размораживаются, например, по 10% в месяц. Или какой-нибудь умный кошелек на смарт-контракте, который мне позволяет, допустим, моим горячим ключом тратить не больше Х денег в месяц, или какими-нибудь двумя ключами тем более, там 10Х денег в месяц. Или, не знаю, еще какая-нибудь комбинация. То есть, это все можно закодировать в solidity, и вот этот proposal, некоторую часть, по крайней мере этой функциональности он приносит.
Иван Иваницкий: Я вот думаю, а насколько жесткая возможность или невозможность так делать, привязана к тому факту, что эфириум statefull, а биткоин statless? И не является ли тогда вот этот proposal в некотором смысле, некоторым обрезанным стейтом?
Сергей Тихомиров: В каком-то смысле, может быть, и является, тут как-то сложно, честно говоря, с ходу отвечать. Но, сейчас, возможно, здесь дело не в стейте, а дело в некоторой интроспекции, в некоторой функциональности транзакции, которая выполняется не совсем независимо от всего остального, то есть, в биткоине в классическом виде, у нас каждая транзакция, это просто некоторый предикат, я правильно термин использую? Некоторая последовательность логических операций, которая в конце вычисляется либо в true, либо в false, в зависимости от значения аргументов. И в классическом варианте, транзакция не зависит ни от чего остального. Это просто, подпись совпала или нет, тайм-лок прошел или нет. Ну она зависит, да, она зависит, например, от высоты блока и от тайм-стемпа, это может быть. Но она не зависит от того, что делают другие транзакции. То есть, никакая транзакция не знает ничего про другие транзакции. А здесь, как бы очень аккуратно и осторожно приносится это качество транзакции, что транзакция может взаимодействовать с другими транзакциями, но не в момент своего выполнения, а в момент, когда ее будут, когда созданный UTXO будут тратить. То есть, выполнение транзакции уже происходит не в вакууме, а происходит с оглядкой на какую-то другую транзакцию. Например, когда ты будешь тратить свои биткоины, залоченные дополнительным условием, то это условие будет проверяться, вот как-то так.
Да, я про batching еще не договорил. С batching ситуация такая, что с биржи на рынке, где комиссии низкие и биржам все равно, они могут, в принципе каждому клиенту по запросу отправлять отдельную транзакцию, и ничего страшного. Если у нас комиссии становятся большими, и биржи хотят экономить и более рационально использовать блок-спейс, они составляют заявки на выдачу денег нескольких клиентов большую транзакцию и экономят на некоторых накладных расходах, насколько я понимаю. Если будет реализован CHECKTEMPLATEVERIFY, тогда биржи могут амортизировать свои расходы на комиссии. Например, если у нас вдруг происходит период с высокими комиссиями, то в текущей ситуации, если биржа хочет оправдать доверие всех своих клиентов, ей приходится платить много денег за комиссии, чтобы всем выдать деньги. В этом proposal’е, она сможет сконструировать одну хитрую транзакцию, которая создаст UTXO, который каждый клиент сможет потратить потом. И, насколько я понимаю, вот я на самом деле сейчас вот это объясняю и понимаю, что я не полностью убежден. Но идея в том, что для бизнеса это будет дешевле в данный момент, когда комиссии высокие. При этом все клиенты смогут посмотреть на блокчейн и увидеть, что действительно, есть такой UTXO, и, действительно, только я смогу его потратить, когда захочу. И дальше, комиссии опускаются, когда-нибудь и каждый клиент может прийти потом и этот UTXO себе забрать. Вот такая оптимизация.
Иван Иваницкий: То есть, в биткоине придумали transfer from?
Сергей Тихомиров: Ты знаешь, в каком-то смысле, да. То есть, разделение передачи денег на два шага. Первый, я тебе разрешаю у меня взять деньги, и второй шаг — ты у меня берешь деньги. Если эти две ступеньки логически разделить, то можно, видимо, более рационально использовать пространство в блоке.
Иван Иваницкий: Ну да, вот тот же transfer from в эфире, используется как раз для этого.
(00:55:00)
Если есть 1000 клиентов, не знаю, биржа, crowdsale не пробегала по ним всем, не тратила кучу эфира, а просто разрешала им, и, соответственно, каждый потом осуществлял withdrawal когда ему захочется. И более того, сам платил за это газ. Кстати, как это устроено вот в этом proposal’е, просто, если я захочу забрать эти деньги, то я буду платить комиссию? Хотя я, честно говоря, даже не до конца понимаю, что в этой парадигме значит забрать.
Сергей Тихомиров: Забрать — значит перевести биткоины из того UTXO, который позволяет тебе их перевести только в определенное место, перевести их в это определенное место, то есть, на свой адрес, а уже со своего адреса, ты их можешь отправлять куда угодно, то есть, в этом смысле забрать. А комиссию ты платишь, исходя из того, исходя из того, какой размер, точнее какой вес имеет твоя уже транзакция, и насколько сложный скрипт ты хочешь соорудить в том месте, уже полностью под твоим контролем, куда ты хочешь эти деньги перевести.
Иван Иваницкий: Окей, понятно. Что-то еще там было интересное, в этом докладе?
Сергей Тихомиров: Еще один пункт про batching и про биржи. Докладчик это объяснил с картинками, и картинки там такие красочные, что их сложно пересказывать, разные хитрые конструкции, древовидные конструкции из транзакций. Я уж тут, честно говоря, не буду пытаться их пересказать в аудио-формате, но идея заключается в том, что биржи с помощью этой конструкции смогут, в кавычках, дискриминировать своих клиентов, и приоритизировать тех клиентов, которые предположительно им заплатили больше за сервис более быстрого вывода. То есть, насколько я опять-таки понимаю и помню, что вот в этих вот транзакциях, которые всем выдают деньги, с ограничениями на то, куда можно эти аутпуты потратить, можно в первую очередь собрать всех VIP-клиентов в одну транзакцию и отправить ее, и они уже, в первую очередь, получат эту возможность, выводить. А потом уже собрать каких-то больше простых ребят, и они получат эту возможность чуть позже. То есть, здесь чего-то я могу на самом деле, перевирать, так что посмотрите доклад. Там красивые диаграммы и красивые такие древовидные конструкции, которые из такого рода транзакций можно собирать.
Иван Иваницкий: Да, там даже на подобие мультика сделано, где монетки текут из cold storage (холодного хранилища -прим.) на вот этот промежуточный этап, из него уже на hot storage. Окей, тогда перейдем к следующему докладу. Это у нас Node Modes: Taxonomy of Bitcoin Network Nodes плюс an addition Tadge Dryja, девелопер в MIT DCI. О чем же был этот доклад?
Сергей Тихомиров: Да, доклад, фамилию этого человека я тоже очень долго не знал, как произносить, но, вроде бы, это Дража. Это со-изобретатель Лайтнинг Нетворка. Доклад его состоял тоже из двух логических частей. И он рассказал вначале про то, какие бывают биткоин-ноды. И он выделил несколько функций, которые должны биткоин-ноды выполнять, и разные комбинации, разные варианты нодов могут разные комбинации этих вещей выполнять. Как распространять транзакции в блоке, валидировать транзакции, посылать транзакции, принимать их и майнить. И дальше, по мере развития биткоина, понятие фулл-ноды, оно расширялось и люди понимали, что не всем пользователям нужно выполнять все эти операции и возникли разные комбинации, разные варианты нодов, помимо собственно full node.
И самая главная вещь, по мнению докладчика, что такое на самом деле полный нод. Это нод, который валидирует все транзакции. И это необязательно нод, который все хранит, потому что, как мы говорили выше, может быть такой режим синхронизации с блокчейном, где ты скачиваешь блоки, ты их проверяешь по мере того, как они скачиваются, потом ты их выбрасываешь, уже их проверив, и тогда, ты будешь полным нодом в том смысле, что тебе никому не нужно будет доверять, чтобы проверять валидность своих транзакций и вообще всех транзакций. Но с другой стороны, тогда ты не сможешь помогать другим, не сможешь другим загружать блокчейн. Ну, не можешь и не можешь. Да, бывают также узлы, у которых, так называемый, pruned блокчейн, где выкинуты старые куски. Бывают также узлы, которые обладают индексированным блокчейном, потому что с точки зрения баз данных и хранения данных, тот формат данных, который Bitcoin Core использует внутри себя, он, насколько я понимаю, не очень хорошо приспособлен под какие-то рандомные запросы. То есть, не очень просто, точнее, это относительно медленно, взять хэш транзакции и сказать, а скажи мне, а в каком блоке была вот эта транзакция.
(01:00:04)
То есть, в принципе, придется с самого начала сканировать блокчейн, пока ты не набредешь на этот блок. Для того, чтобы это было быстрее, можно поставить режим с индексированием и тогда, по мере того, как ты сканируешь блокчейн, ты дополнительную структуру данных создаешь, где быстро можно искать транзакции по хэшу, блоки по хэшу и, возможно что-то еще можно искать. Это чисто опционально, это будет больше места занимать на жестком диске, но это полезно, если ты хочешь дальше работать с блокчейном и из него извлекать какую-то информацию.
Также, нам докладчик рассказал про SPV упрощенную верификацию платежей, это очень старая идея, давно имплементирована, и он рассказал про то, чем собственно модель безопасности отличается от обычного узла, который полностью все валидирует. А отличается она тем, что в случае SPV, я вообще не проверяю валидность транзакций. То есть, я прошу некоторый сервер, чтобы он мне сказал, какой сейчас блок, и чтобы сервер предоставил мне меркл-пруфы, доказательства того, что транзакции, которые меня интересуют, входят в какой-то блок из подтвержденных. Но при этом, я совершенно не имею никакого понятия, что там вообще в этом блоке происходит. Может, там было что-то невалидное.
Что мне позволяет с какой-то степенью уверенности это принимать как истину, это то, что я могу проверить proof of work. То есть, мне пересылается заголовок блока, я смотрю, что действительно на нем сделан качественный proof of work. Возможно, конечно, это злонамеренный fork. Возможно, меня пытаются здесь обмануть. Мне подсовывают какой-то невалидный блок, который образовался в результате атаки 51%. Но если речь идет о небольших суммах, если я готов взять этот риск на себя, то это, в общем-то, разумный компромисс, на который можно идти с точки зрения безопасности. Но это, возможно, не совсем разумный компромисс, если я при этом являюсь майнером. То есть, если я профессионально занимаюсь майнингом, то мне лучше все-таки иметь свою полную ноду и валидировать все независимо. А то у нас были прецеденты, когда майнеры валидировали с помощью spv. И я не помню, честно говоря, какой именно баг, какое-то нестандартное положение вещей, привело к тому, что майнеры, которые майнили с spv, потеряли деньги. Они майнили на каком-то fork’е, который в итоге оказался невалидным. То есть, это такие общие на самом деле вещи, Тоже, скорее всего, большинство из этих вещей не секрет для тех, кто давно в биткоине, ну а тем, кто недавно, как раз очень полезная информация, чтобы понимать что вообще такое нода, какие они бывают. Это первая часть доклада, касалась таких вводных вещей.
А вторая часть доклада, там Тадж Дража рассказал про свой собственный проект, который он реализует для bitcoin core, который называется U3XO. Не путать с Assume UTXO. Вот раньше мы обсуждали Assume UTXO, а это U3XO. Тоже, как следует из названия, имеет отношение к UTXO сету, но здесь уже докладчик подходит с другой стороны к проблеме. Именно, что в том сценарии, который мы рассматривали выше, когда я хочу у кого-то взять UTXO сет, то все-таки мне придется эти 3-4 гигабайта у кого-то скачать. А вот было бы здорово, думает Тадж Дража, чтобы всю информацию о текущих UTXO, о текущих непотраченных биткоинах, можно было бы компактно упаковать в так называемый аккумулятор. Аккумулятор — это такая криптографическая конструкция, в которую можно складывать разные вещи, а потом проверять, что вещи туда действительно были положены. То есть, в каком-то смысле, наверное, криптографы меня поправят и, возможно, я не совсем строг в терминах, но в каком-то смысле меркл-дерево — это тоже аккумулятор, то есть, я могу положить туда какие-то вещи, а потом компактно, а потом проверить, что действительно данные какие-то туда были положены. И идея U3XO состоит в том, чтобы в аккумулятор завернуть, собственно, множество UTXO, и это открывает некоторый простор для оптимизации. Например, как докладчик говорит и показывает на данных, показывает на анализе самого блокчейна, UTXO имеет очень разную длительность жизни, и факт, который у меня вызвал удивление, оказывается, что наиболее популярное время жизни UTXO — это 0 блоков. То есть, большая часть UTXO тратится в том же блоке, в котором он создается, что немножко странно. И вообще, гораздо больше UTXO имеют… Если начертить график и построить такую гистограмму возрастов UTXO на тот момент, когда они были потрачены, то получается, что UTXO, которые умерли молодыми, гораздо больше, чем тех, которые умерли старыми. Постоянно происходит какой-то трейдинг, видимо постоянно происходят какие-то обмены, UTXO они порождаются и сжигаются, порождаются и сжигаются.
(01:05:00)
И из этого можно выдать оптимизацию. В этом аккумуляторе можно как-то… Сейчас, здесь я уже немножко плыву, но вроде как, можно приоритезировать эти UTXO и как-то сделать так, чтобы как некоторые hot-storage и cold-storage, чтобы у нас быстрые UTXO, по ним можно сделать быстрый look up. А медленные UTXO хранились где-то больше в холодном хранилище ноды. И, таким образом, у меня будут быстрее работать ноды потенциально, потому что я валидирую очередной блок, очередные транзакции. И в следующем блоке, тратятся в основном UTXO, которые были созданы в предыдущем блоке или несколько блоков назад. Если эти предыдущие несколько блоков UTXO у меня будут в кэше, тогда я смогу их быстро валидировать, а те UTXO, которые очень далекие, давние, скорей всего UTXO пролежал там несколько лет, то он может еще и несколько лет пролежать. И тогда это можно отложить, наоборот, в более долгосрочное, в более медленное хранилище. Вот какая-то такая идея упаковывать UTXO в аккумуляторы.
Иван Иваницкий: Да, честно говоря, я в какой-то момент перестал понимать, как это связано с тем, какие ноды у нас бывают. Если ты напомнишь, будет круто.
Сергей Тихомиров: Ну, честно говоря, это не очень сильно связано, то есть, в каком-то смысле это связано так, что этот аккумулятор из UTXO позволяет нам, возможно, хотя я не уверен, что это было в докладе, это уже от себя додумываю, что это у нас будет некоторый такой промежуточный тип full-нода, который не совсем full, но тем не менее, у него есть вот этот аккумулятор. Просто некоторая новая точка на этом пространстве, возможных, дизайнов, относительно того, храним ли мы стейт, скачиваем ли мы стейт и как мы его валидируем.
Иван Иваницкий: Окей. Тогда, если ты не против, я бы предложил перейти к последнему, наверное, докладу, который мы отметили с тобой. Это What is Bitcoin Being Used For — для чего используется биткоин.
Сергей Тихомиров: Да, здесь, наверное, я в кратце так очень по нему пробегусь. Его, к сожалению, у меня не записано здесь имя, кто автор этого доклада, у тебя есть под рукой?
Иван Иваницкий: Слушай, нет, у меня тоже не написано.
Сергей Тихомиров: Ну, автор этого доклада (Antoine Le Calvez — прим.), это автор сайта p2sh.info. Это сайт, который показывает разную интересную статистику, относительно того, какие транзакции происходят в биткоине, какие блоки. Как транзакции распределяются по разным их параметрам, сколько процентов использует segwit, такого рода вещи. Собственно, доклад представлял некоторые результаты анализа блокчейна биткоина по тому, какие там транзакции, какие там UTXO. Несколько интересных инсайтов, которые мне показались любопытными. Во-первых, в ранней истории биткоина, был такой момент, когда суммы, передаваемые в транзакциях, перестали быть круглыми. В смысле, количество биткоинов. Есть ли предположения, почему?
Иван Иваницкий: Ну, первое предположение, которое мне приходит в голову, это просто подрос курс, и один биткоин стал означать гораздо больше долларов, но и, более того, дальше это можно продолжить так, что со временем мы просто переходим на следующую цифру, после запятой.
Сергей Тихомиров: Тепло, но не совсем. На самом деле, переход этот произошел в тот момент, когда у биткоина вообще появился курс. То есть, в первые год-два развития биткоина, никто на самом деле не знал, сколько биткоин стоит, поэтому те транзакции, которые тогда были, это были чисто транзакции между разработчиками-энтузиастами, для тестирования системы в основном. Поэтому люди переслали друг другу… Ну, ты мне пошли 1000 биткоинов, для ровного счета. Или 10000. И транзакции были в такого порядка величинах круглые. В тот момент, когда открылась биржа mt.gox, и на ней стали более или менее достаточного объема торги, чтобы биткоин приобрел какой-то определенный курс, тогда уже люди стали обмениваться биткоинами в смысле какого-то количества долларов по mtgox’у и, соответственно, суммы транзакций биткоина перестали быть круглыми. Интересный такой поинт. Это было еще, у меня не записано, но насколько я понимаю, это было в году 2011. Дальше в году 2012-2013 произошел Satoshi Dice. Это было казино на блокчейне, казино на биткоине, где предлагалось отправить транзакцию на какой-то адрес, и дальше он, с помощью рандомного процесса, мог выдать или не выдать какое-то количество Satoshi обратно. Что-то такого рода. И Satoshi Dice занимал 40% транзакций биткоина в 2012-2013 годах. Одно предложение — это просто крипто-kitties в мире биткоина, я считаю. И когда уже комиссии стали слишком большие, ну, по нашим меркам, они может быть стали не слишком большие, достаточные, чтобы платежи, чисто номинальные, сделать неэкономически выгодными, тогда Satoshi Dice и перестал работать так, как он был задуман.
(01:10:03)
Дальше в докладе было несколько интересных фактов про внедрение pay to script hash и про внедрение segwit. Тут я не буду углубляться тоже в детали, посмотрите, там все с графиками, как в биткоине шел в adoption технологии, и как они постепенно внедрялись в конкретные транзакции, потому что это же мультиступенчатый, на самом деле, процесс. И когда мы говорим, что вот у нас очередное обновление в биткоине, как тот же самый Taproot, который мы обсуждали, или подписи Шнорра, это на самом деле три разных этапа проходит каждое обновление. Во-первых, разработчики Bitcoin-core выкатывают его в код Bitcoin-core. Это первый этап. Второй этап — кошельки начинают это поддерживать, потому что если я не пользуюсь Bitcoin-core, а пользуюсь какой-нибудь биржей или другим кошельком, уже разработчикам этого кошелька нужно позаботиться, чтобы это имплементировать, чтобы их кошелек смог генерировать транзакции по новой схеме. Это второй этап. А третий этап — если даже мой кошелек обновил свой код, то мне еще нужно свои UTXO потратить и перевести на адрес, соответствующий новому стандарту. А я могу этого не хотеть делать, потому что, в принципе, особых причин этого делать у меня нет. Так что, adoption таких вещей, как pay to script hash и segwit, идет очень постепенно. И вот на графиках в докладе можно посмотреть, как именно он шел.
Также, мне показался интересным такой факт, что в транзакциях на блокчейне биткоина, прослеживается сезонность, причем довольно сильная. Во-первых, она прослеживается в цикле день-ночь, из чего можно сделать предположение, что большая часть пользователей биткоина находится в Западной Европе, вообще в Европе и США. Тогда, когда в Европе и Америке ночь — транзакций меньше. Когда там день — транзакций больше. Например, в этом смысле Азия еще не вовлечена, хотя там живет больше людей, чем в Европе и в Америке. Все равно, когда в Европе и Америке ночь, в Азии-то день. Получается, биткоин-транзакций они отправляют гораздо меньше. И, во-вторых, виден паттерн, что в выходные меньше транзакций, чем в будние дни. То есть, не знаю, какой из этого вывод сделать, но такое интересное наблюдение. Ну, наверное, я бы закруглился с этим докладом, посмотрите, там больше информации в картинках и графиках, чем разумно пересказывать словами.
Иван Иваницкий: Я, почему-то, ожидал от этого доклада каких-то более детективных историй, в духе Bellingcat. Типа, такого-то года, биткоином в основном пользовались наркоторговцы, потом им стали пользоваться коррумпированные чиновники. До такого-то года, самой крупной тратой была покупка пиццы Холлоу Фини и так далее. И максимально интересно было бы узнать, для чего биткоин в основном используется сейчас, потому что, ну, я вообще себе не представляю ни по объемам денег, ни по количеству транзакций, какая деятельность сейчас в нем доминирует.
Сергей Тихомиров: Ну, здесь, к сожалению, я ответить на это не могу. потому что доклад, действительно, возможно, он немножко назван так кликбейтно, чтобы привлечь внимание. На самом деле это, по большому счету, анализ блокчейна.
Иван Иваницкий: Но вот круто было бы присовокупить к этому анализу блокчейна, по аналогии опять же с Беллинг Кэт, анализ каких-то других данных. Я уверен, что они есть, другой вопрос, что не понятно, какого рода эти данные. Фотографии или, может, движения в банковских счетах или, может быть, следы на наличных, даже не знаю, что предположить. Но мне кажется, что-то такое должно быть, и выводы могут быть там очень интересные. Другой вопрос, непонятно, кто бы мог этим заняться. Кто, с одной стороны, достаточно хорошо понимает биткоин, а с другой стороны, который хорошо понимает какие-то расследования в классическом мире.
Сергей Тихомиров: Ты знаешь, мне кажется, что этим занимаются Chainalysis. Это как раз и есть то, чем занимается блокчейн аналитика. Не знаю, хотят ли они нам об этом рассказывать, но текущий доклад точно был не про это.
Иван Иваницкий: Ну что же, давай тогда пробежимся по еще одному докладу. The Promise and Perils of Non-Deterministic Bitcoin Scripts. Это широко известный Джеймсон Лопп. Обещания и Perils, не помню что это…
Сергей Тихомиров: Ну, типа беды.
Иван Иваницкий: Да. И Беды Нон-Детерминистических Биткоин Скриптов.
Сергей Тихомиров: Отлично перевел.
Иван Иваницкий: Но, вообще, я помню, у нас выпуск был, в котором мы говорили про governance и там перевод заключался в основном в том, чтобы говорить английские слова с русским произношением.
Сергей Тихомиров: Да, как мы любим. Да, я хотел очень вкратце рассказать про этот доклад, точнее не столько про него рассказать, сколько адресовать слушателей к нему, потому что, мне кажется, он поднимает очень важную проблему с безопасностью хранения биткоинов, о которой мало кто думает и мало кто вообще знает, что проблема есть.
(01:15:07)
Как мне кажется, многие люди считают, что если они забэкапят свои ключевые слова, сид-фразу своего кошелька и будут хранить это в надежном месте, то они всегда смогут свои биткойны восстановить. И это в принципе, скорее, правда, но нужно иметь в виду очень интересную деталь. Что могут существовать разные способы и разные протоколы. Как из этих скольких-то английских слов получить приватные публичные ключи. И кошельки, хотя существует на эту тему стандарт, которому, по идее, кошельки должны следовать. Этому стандарту следуют не все кошельки. И иногда получаются очень нехорошее ситуации, когда у меня есть биткоины в каком-то кошельке, я записал его ключевые слова. Потом этот кошелек, допустим, это был какой-нибудь веб-кошелек или мобильный кошелек, который был не кастодиальный, там not your keys, not your coins. Хорошо, все ключи у меня, но при этом исходный код закрыт. А кошелек где-нибудь в appstore и, например, выложен. А потом компания обанкротилась, кошелек пропал, у меня остались эти ключевые слова, за которыми скрываются биткоины. Но между словами и биткоинами еще есть некоторый алгоритм выведения этих ключей, деривация этих ключей. Если кошелек это не документировал нигде, если source code не открыт, то никто не может мне биткоины достать. Для того, чтобы пользователи понимали эту особенность хранения биткойна, есть сайт, называется walletsrecovery.org, где перечислены разные кошельки и то, насколько хорошо у них документирован процесс восстановления из слов ключей. Там вы можете посмотреть и проверить, что ваш кошелек действительно, в случае если что-то случится с его разработчиками, с компанией, которая разрабатывает и так далее, убедитесь, пожалуйста, что кошелек документирует процесс деривации ключей. Иначе может быть очень нехорошая ситуация. Посмотрите доклад. Мне кажется, это очень важная тема.
Иван Иваницкий: Я недавно ходил к моим друзьям на канал записывать ролик про bitcoin, который, я надеюсь, скоро выйдет. Я думаю, мы широко его прорекламируем в каналах Базового Блока. И там один из вопросов, на которые я отвечал, это «Какой же лучше выбрать кошелек?» Видимо, этот вопрос со временем становится все более и более сложным. Новичок теперь столкнется не с тем, что «Да выбирай любой кошелек, все нормально!», а с тем, что «Убедись, что там используется стандартный алгоритм получения ключей из сид-фразы». Что сразу может ввести человека в некоторый ступор. И в этом смысле, наверное, этот вопрос нужно решать при помощи репутации, в том смысле, что есть какие-то стандартные широко распространенные кошельки, и надеяться, что они следуют всем стандартным практикам безопасности. И, к сожалению, как мы знаем, часто эти надежды не оправдываются.
Сергей Тихомиров: Ультимативный здесь выбор — это bitcoin-core, потому что bitcoin-core определяет то, чем является биткойн. Я понимаю, конечно, что у большинства пользователей требования другие. По производительности им хочется что-нибудь на телефонах, это абсолютно оправдано. Изучайте сайт walletsrecovery.org.
Еще есть сайт, называется walletscrutiny. Там тоже человек собрал такую табличку по кошелькам, только он взял один аспект безопасности. Он посмотрел, у каких кошельков есть открытый исходный код, и насколько то, что они выкладывают в appstore и в google play, насколько она детерминично «билдится» из выложенного source кода. Потому что если это не так, то чтобы они не опубликовали на github’е, мы не можем на самом деле утверждать, что этот кошелек на самом деле делает на моем телефоне. Так что, это еще один аспект, на который можно обратить внимание. Есть хорошие сайты, есть google-таблички, которые сообщество собирает, где плюсы и минусы, и особенность разных кошельков сравниваются друг с другом. Так что, если вы хотите хранить существенную сумму, то отнестись ответственно к выбору своего кошелька.
Иван Иваницкий: Ну, на этой security- friendly ноте, я предлагаю завершить наш сегодняшний разговор. Друзья, спасибо, что слушали the-подкаст про блокчейн на русском. Сергей, спасибо за твой рассказ.
Сергей Тихомиров: Спасибо большое.
И спасибо большое еще раз нашим патронам на patreon.com/basicblockradio.
И спасибо нашим спонсорам. Наши спонсоры – это «Zerion» — приятный и простой интерфейс к миру DiFi.
Это «Solana» — самый быстрый блокчейн без шардинга с proof of history. Токены Solana есть на Binance. Есть русскоязычное комьюнити в телеграме и вконтакте.
А также «Hodlhodl» — это быстрый безопасный дешевый способ купить и продать биткоины без верификации. Они выкатывают очередной шаг своего редизайна, пользоваться им будет еще лучше и еще удобнее. И зарегистрировавшись по нашей специальной ссылке в описании, вы получите скидку на комиссию.
Спасибо большое нашим спонсорам, и спасибо большое нашим слушателям за внимание.
Иван Иваницкий: Спасибо тебе, Сергей. С вами были Иван Иваницкий и Сергей Тихомиров. Подкаст «Базовый блок». Всем удачи. Пока.
(01:20:00)