ББ-117: Сетевые протоколы для блокчейнов и файлообмена

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

  • 01:00 спасибо патронам и спонсорам: Zerion, HodlHodl и Solana!
  • 03:50 фундаментальный вопрос: насколько опыт файлообмена применим к блокчейнам?
  • 05:50 интернет изначально разрабатывался устойчивым
  • 09:00 две задачи файлообмена: найти файл и скачать его
  • 10:10 краткая история файлообменных сетей от Napster к BitTorrent
  • 15:20 адресация контента в BitTorrent
  • 17:10 DHT, Kademlia и IPFS
  • 18:30 оказывается, у IPFS нет Sybil protection
  • 20:30 нужна ли защита от Sybils для файлообмена?
  • 22:50 файлшеринг как предвестник блокчейнов
  • 29:30 цели дизайна для сетевого уровня биткоина
  • 31:20 сетевой уровень биткоина — часть цельной системы
  • 32:30 блокчейн как общий набор данных
  • 33:40 синхронизация блокчейна не заканчивается никогда
  • 35:00 нет проблемы адресации: блокчейн одинаковый у всех
  • 36:00 Kademila и eclipse-атаки в Ethereum
  • 38:20 данные блокчейна имеют логическую структуру
  • 43:50 верификация транзакций
  • 45:30 две роли в файлообмене и в блокчейне
  • 49:30 мотивации и приватность: зачем поддерживать полные узлы
  • 52:30 три задачи для блокчейна
  • 56:30 почему важна приватность в криптовалютах
  • 1:01:40 два пути для атак на приватность
  • 1:08:00 итог: как дизайнить P2P-протоколы

Ссылки:

Спасибо нашим спонсорам:

  • Подкаст выходит при поддержке Zerion – понятного интерфейса к DeFi-протоколам. 
  • Подкаст выходит при поддержке HodlHodl – площадки для покупки и продажи биткоинов без верификации. Зарегистрируйтесь и получите скидку на комиссию! 
  • Подкаст выходит при поддержке Solana – быстрого блокчейна без шардинга. Токены SOL доступны на Binance с 9 апреля, подробности на solana.com и в телеграме @solanarus.

 Поддержите подкаст!

 https://basicblockradio.com/ 

ББ117

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

Я сегодня один в своей люксембургской студии записываю этот выпуск. Сегодня он будет посвящен несколько более фундаментальным вещам, чем какой-то конкретный проект. Сегодня я постараюсь рассказать про файлообмен и P2P-уровень, насколько уроки BitTorrent и прочих файлообменных сетей применимы к блокчейнам. 

Но прежде чем мы к этому перейдем, я бы хотел сказать «спасибо», во-первых, нашим патронам. На patreon.com/basicblockradio можно нас поддержать, и мы, конечно, ваше пожертвование используем с умом и с пользой. Например, мы сделали расшифровки для последних выпусков: №116 – про «Чёрный четверг» в DeFi и №115 – про коронавирус и его влияние на экономику, и в том числе блокчейн. Вы можете на нашем сайте basicblockradio.com почитать эти расшифровки очень высокого качества. Так что, если кому-то больше нравится читать, чем слушать, то Welcome! 

Призываем также всех подписываться на нас во всех каналах, социальных сетях, Telegram особенно. У нас есть там ББ-чат. Там очень оживленные и при этом спокойные, и высоко, скажем так, интеллектуальные дискуссии происходят постоянно.

Также спасибо большое мы говорим нашим спонсорам. Сегодня у нас такой расширенный спонсорский блок. Во-первых, мы благодарим Hodl Hodl. Hodl Hodl нас поддерживает. Это самый быстрый и безопасный, и дешевый способ купить и продать биткоины без верификации. У нас есть специальная ссылка в описании. По ней вы можете зарегистрироваться и получить постоянную скидку на торговую комиссию. А также специальное сообщение от Hodl Hodl следующего содержания: значительно улучшен был дизайн торговой платформы, и благодаря этому платформа стала намного проще в использовании. Работа над редизайном продолжается, и команда намерена значительно улучшить все свои продукты. Кроме того, благодаря своему API, Hodl Hodl уже представил множество интеграций, последняя из которых – это интеграция с Blue Wallet.

Тут я уже добавляю от себя, что Игорь Корсаков, разработчик Blue Wallet, был в гостях «Базового блока», в выпуске №108. Послушайте, если вы хотите узнать о том, как устроены Lightning и Bitcoin-кошельки изнутри.

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

Также мы благодарим Zerion, простой и приятный интерфейс к миру DeFi. 

И также мы благодарим Solana. Solana – это наш новый спонсор. Они нас поддерживают, и представитель CEO Solana, Анатолий Яковенко, был у нас в выпуске №114. Solana – это быстрый блокчейн без шардинга, proof-of-history, блоки раз в 400 миллисекунд. 

Можете послушать выпуск со всеми техническими подробностями. У них сейчас проходит соревнование Tour de SOL, где можно протестировать сеть и получить вознаграждение. Они активно развивают в том числе русскоязычное комьюнити, у них есть Telegram-группа Solana RUS, также есть группа «Вконтакте». Заходите – они с удовольствием отвечают на все вопросы и проясняют все детали.

Большое спасибо нашим спонсорам.

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

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

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

(00:05:07)

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

Если начать вообще сначала, то сам Интернет с самого начала разрабатывался с таким дизайном, чтобы быть устойчивым к потерям, и протоколы Интернета, которые разрабатывались, начиная, я думаю, с 60-х годов и в 70-х годах (тот же TCP/IP), они разрабатывались из расчёта такого, что какие-то серверы могут быть недоступны, могут отвалиться, могут взорваться, и тем не менее, информация должна распространяться по сети, даже если большая часть узлов выпала. 

Есть разные мнения о том, насколько такие решения в дизайне были мотивированы возможной ядерной войной между США и СССР и насколько действительно важным пунктом в этом ТЗ, которое выдвинули разработчикам Интернета, было именно обеспечить связанность командования американской армии в случае ядерной войны, но, как бы то ни было, в итоге дизайн получился очень устойчивым, устойчивым к ошибкам, устойчивым к падениям, и именно потому, что он таков, мы и пожинаем плоды (в хорошем смысле), мы наслаждаемся Интернетом и наслаждаемся его таким свойством, что какие-то сервера могут временно отключиться и тут же нагрузка может быть переброшена на другие сервера. Пакеты находят свой маршрут в сети независимо, и нет никакого центрального сервера, нет никакой такой единой точки, находящейся под централизованным контролем, которая бы распределяла пакеты – куда какой пакет пойдёт и по какому маршруту какой пакет будет перенаправлен. Пакеты пересылаются через конкретные роутеры, и конкретные роутеры в зависимости от своих сетевых таблиц, от того, насколько они представляют архитектуру сети или по крайней мере ближайшей окрестности сети, они принимают локальное решение о том, куда направить этот пакет. То есть, вот ко мне пришёл пакет, и я думаю: «Так, из моих соединений какое наиболее близко к пункту назначения? Вот, вот такое-то», и отправляю туда. Так что эта архитектура очень устойчива.

Но давайте тут не будем долго задерживаться и не будем углубляться. Я хотел главным образом поговорить всё-таки про развитие сетей не в такой древней древности, как 60-70-е, а скорее уже в поздние 90-ые, ранние 2000-ые, когда на сцену вышли, конечно же, файлообменные сети. 

Не секрет, что Bitcoin был, в том числе, инспирирован, вдохновлён BitTorrent, и даже Сатоши в одном из своих комментариев (вы знаете, наверное, есть такие подборки цитат Сатоши, в частности на сайте nakamotoinstitute), вот есть хорошая подборка цитат Сатоши, сгруппированных по разным темам. Там одна из цитат звучит примерно так (я близко к тексту цитирую), что правительство успешно запрещало разные централизованные штуки, но против децентрализованных сетей, таких как BitTorrent, выяснилось, что они ничего сделать в конечном счете не могут. То есть, Сатоши определённо про BitTorrent знал и вдохновлялся этим примером, скорее всего, когда разрабатывал Bitcoin.

Но мне показалось интересным подумать о том, на самом деле чем похожи и чем не похожи задачи, которые решает BitTorrent, и задачи, которые решает Bitcoin.

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

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

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

(00:10:07)

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

Это был хороший такой proof of concept, который показал, что, в принципе, с системами такого рода можно работать, но нужно, конечно, сделать их более устойчивыми к внешнему вмешательству. И другой подход, в некотором смысле не то, чтобы противоположный, но другой полюс, скажем так, такого спектра разных подходов к адресации контента – это Gnutella, которая (я не изучал глубоко эту тему, насколько я понял по описанию из Википедии, по крайней мере первая версия Gnutella) просто использовала flooding как механизм поиска запросов. То есть, я просто отправляю каким-то пирам в сети вопрос: «А нет ли у тебя такого файла? Если у тебя есть такой файл, то давай мне его, а если нет, то передай этот запрос всем, кого ты знаешь». И так эти запросы рассылались по сети просто такой лавиной, и если у кого-то этот файл есть, конечно, эти запросы рано или поздно до него доходили. 

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

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

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

Для чего бывает полезен файлообмен и в каких случаях он выполняет задачи, которые, по крайней мере по состоянию на ранние 2000-ые, нельзя было сделать или было очень сложно сделать легальными способами? С одной стороны, это распространение очень свежего контента. То есть, альбом, условно говоря, украденный с завода за 2 недели до релиза, сливают в сеть, и ты его уже можешь послушать, хотя легально ты его ещё не можешь купить. Это одна грань этой пользы для юзера, которую приносит файлообмен. А другая грань – это, наоборот, очень старый контент (архивные какие-нибудь фильмы, редкие фильмы, редкая музыка), который не продается в широких сетях, и если ты живёшь не в крупном мегаполисе, где есть какой-нибудь магазин музыкальных раритетов, если ты живешь в небольшом городе, то у тебя просто нет никакого способа легально приобрести старые редкие аудиозаписи или старые редкие фильмы. 

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

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

(00:15:01)

Скорее всего, если вы пользовались или пользуетесь такими сайтами, как The Pirate Bay, такими сайтами, как RuTracker, и кто-то, может быть, даже помнит те времена, когда этот сайт назывался torrents.ru, то обычно как это происходит: заходишь на сайт, выбираешь раздачу, которая тебе интересна, скачиваешь торрент-файл, открываешь его в торрент-клиенте, и торрент-клиент начинает скачивать.

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

Но это не единственный механизм, которым можно находить файлы. Можно использовать децентрализованные хэш-таблицы (DHT), которые более медленные, но которые более в каком-то смысле надёжные и децентрализованные. Это такая богатая идея, которая получила своё развитие впоследствии, и в последней версии это уже называется IPFS – проект, который имеет непосредственное отношение уже к блокчейну, хотя не является блокчейном сам по себе. Это тоже ни что иное, как очередная реинкарнация той же идеи распределенной хеш-таблицы.

Также одна из известных имплементаций называется Kademlia, и много вещей основаны на Kademlia, в частности так называемые trackers list torrents, то есть торренты, которые можно скачивать по так называемой magnet-ссылке, в которой зашифрованы параметры файла, при этом без конкретного референса к конкретным каким-то узлам, которые этот файл содержат. И вот эта идея децентрализованной хеш-таблицы, собственно, это некоторый компромисс, некоторая оптимизация того подхода, который был в Gnutella, когда мы всем отправляем запросы. Здесь мы отправляем запросы не всем, а только отправляем запросы примерно в тот участок сети, который, скорее всего, хостит тот файл, который нам хочется. То есть, собственно, вся идея заключается в том, что, ну очень грубо говоря, от каждого файла берётся хеш, дальше мы делим эти хеши на какой-то количество бакетов, то есть берем там последнюю шестнадцатеричную цифру и, в зависимости от её значения, мы делим все файлы на 16 корзиночек. Дальше у нас один компьютер отвечает за нулевую корзиночку, другой компьютер – за первую корзиночку, третий компьютер – за вторую корзиночку и так далее, то есть некоторый абстрактный псевдорандомный механизм распределения файлов между участниками сети. 

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

Я пока ресёрчил эту тему, кстати говоря, я упомянул IPFS. Нашел статью, приложу, наверное, её в описании, называется “Mapping the Interplanetary Filesystem”, которую написали исследователи из Берлина, со многими из которых, кстати говоря, я встречался на конференциях: и на Берлинской блокчейн-неделе, и на каких-то ещё конференциях. Слежу за их работой (Университет Гумбольдта в Берлине). 

Они провели исследование про IPFS, и я подробно его не прочитал. Они, собственно, что сделали: они решили померить, сколько там вообще узлов, какая там активность, и написали программу-crawler, которая всю эту сеть пощупала. Но что мне показалось интересным, что они не обнаружили в IPFS никакой защиты от sybil-атак.

То, о чём я раньше не упомянул, а упомянуть, наверное, нужно, что все вышеописанные механизмы адресации и все эти DHT, и Kademlia, и так далее – всё это в каком-то смысле основано на доброй воле участвующих узлов. То есть, если я подключаюсь к этой сети, мой софт генерирует, например, айдишник моего узла, и дальше как бы все соглашаются, и я соглашаюсь с тем, что если протокол мне говорит, что вот этот файл, у него такой хеш, он совпадает в каком-то смысле с хешем, с айдишником моего узла – значит, я его должен хранить. Я такой говорю: «Ну окей. Значит, я буду хранить», – и храню его действительно, и отдаю его по запросу. 

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

(00:20:03)

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

У того же RuTracker/Torrents.ru была когда-то очень давно система, где нужно было поддерживать определенный коэффициент между тем, сколько ты скачал, с тем, сколько ты раздал. Но понятно, что при большом желании всё это можно было подкрутить (такая борьба щита и меча). Но всё-таки это не привело к полному краху подобного рода систем.

Мне показалось интересным в статье про IPFS, что, несмотря на то, что IPFS рекламируется и продвигается как некоторая новая инкарнация, новое поколение сетей, у меня всё время на самом деле возникал вопрос, на который я не мог найти прямого ответа, собственно, чем это принципиально отличается от той же Kademlia, ну, собственно, от обычного файлшеринга. И как-то между строк мне казалось, что можно было прочитать, что это у нас типа, поскольку такой около блокчейн новый проект, наверное, там как-то решена проблема sybil attacks, наверное, там как-то решена проблема того, что там узлы не могут себе создать репутацию, накрутить или создать себе кучу новых айдишников. Но оказывается, как по крайней мере пишут исследователи из Гумбольдтовского университета Берлина, они на самом деле не обнаружили в исходном коде IPFS никакой защиты от sybil attacks, несмотря на то, что white paper IPFS ссылается на научную статью про Kademlia, где приводится некоторый способ, как якобы можно вести систему репутации в Kademlia и защитить ее от sybil attacks. На самом деле, это ничего не реализовано. Вот если вы просто задумывались тоже над этим вопросом, видимо, ответ такой. Но почитайте статью. Опять-таки тут я понимаю только в той степени, в которой это написано в статье.

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

Как нам показали BitTorrent и файлообменные сети, действительно можно создать децентрализованную сеть, где будут распределяться файлы между пользователями, и при этом её очень сложно будет полностью закрыть. Тут ещё, конечно, безумно интересная тема с так называемой сценой, с так называемым комьюнити людей, которые оцифровывают разные вещи, которые взламывают программы и выкладывают их в открытой, скажем так, версии бесплатной, которые взламывают DRM во всяких DVD и так далее. Про это есть целые научные статьи про экономическую подоплеку этого сообщества, точнее про удивительное отсутствие этой экономической подоплеки, то есть это сообщество было (оно и есть, видимо, оно и продолжает в каком-то смысле существовать), оно очень альтруистично и нацелено на такую деятельность just for fun: «Мы хотим просто информацию раскрывать, потому что мы хотим, чтобы она была открыта, и мы просто соревнуемся. Наша группа соревнуется с другой группой, кто быстрее или кто лучше выложит или оцифрует какой-нибудь определённый кусок контента, но при этом мы не пытаемся на этом зарабатывать, а даже, наоборот», – как пишут в инфо-файлах, которые сопровождают раздачу на файлообменниках: «Если вам понравился этот контент, купите его легально». 

Вот это такой интересный, скажем так, поворот, и с точки зрения тех же блокчейнов, мы в блокчейнах привыкли рассуждать про всё с точки зрения такой холодной экономики и рациональных агентов, которые вычисляют свою прибыль (условный selfish mining). Вот майнер у нас считает, какая у него ожидаемая прибыль в таком сценарии, в сяком сценарии, и он будет думать, если нужно, будет видоизменять, например, код, который у него крутится на узлах, чтобы получать максимальное количество прибыли. И конечно, это хорошо работает в качестве базовой гипотезы, но вот, например, в файлообмене такое отклонение от стандартной экономической модели с рациональными агентами, оно довольно существенно. 

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

(00:25:01)

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

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

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

Ответ: конечно же, это Proof-of-Work, и в этом лежит, как мне кажется, главная ключевая инновация Bitcoin, именно добавление Proof-of-Work в Framework P2P-сети, для того чтобы распределять влияние в протоколе согласно той энергии, которая была затрачена. То есть, изначально идея Сатоши, которую он формулировал как one-CPU-one-vote (один процессор – один голос), на самом деле, с течением времени эта идея уже превратилась скорее в 1 МВт или 1 ТВт электричества – один голос, но как бы то ни было, это некоторая привязка к реальному физическому миру, которая не позволяет произвольным образом наращивать свое влияние в протоколе без сжигания настоящей физической энергии.

Надо отметить, что Proof-of-Work действует на уровне приложения всё-таки. Это некоторая application-level-штука, которая регулирует то, как ведет себя протокол уже на уровне выше сетевого, то есть наши узлы уже обменялись какой-то информацией, и этот сетевой уровень мы считаем просто существующим в некоторой абстракции, и дальше мы уже принимаем решение относительно Proof-of-Work, кто у нас имеет право блоки производить. 

Но у нас, тем не менее, остается уровнем ниже peer-to-peer слой, который обменивается этими блоками, обменивается транзакциями, обменивается информацией о том, какие узлы входят в сеть, и так далее. И Bitcoin в каком-то смысле разделяет уровень сетевой, уровень P2P, от уровня приложения, что, в общем-то, логично с точки зрения просто разумного сетевого дизайна.

И интересно здесь подумать, что эти два слоя (условный network layer и application layer), application layer у нас защищен от sybil attacks с помощью Proof-of-Work, то есть мы не можем блоков много напечатать. Но сетевой-то уровень у нас, по сути, не защищен, то есть я могу поднять произвольное количество биткоин-узлов с независимыми айдишниками, могу купить себя IP-адресов, наверное, в разных даже подсетях, и таким образом могу, наверное, получить контроль за значительной частью P2P-сети биткоина просто по количеству голов, по количеству узлов. 

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

Здесь позвольте мне перейти к следующему разделу моих заметок, который я озаглавил как “Design goals for blockchain P2P”. Интересно мне представить себя, скажем так, на месте Сатоши и рассуждать в следующем ключе. У меня есть пример BitTorrent, и BitTorrent выполняет хорошо свою задачу, и у меня есть моя идея биткоина. Вот на самом деле те задачи, которые выполняет BitTorrent, они насколько похожи или не похожи на те задачи, которые должен выполнять биткоин? И именно с точки зрения P2P-слоя и распространения информации по сети могу ли я просто взять, допустим, BitTorrent или что-то в этом духе и переиспользовать в Bitcoin, или мне нужно изобретать что-то свое и делать собственный протокол обмена блоками, какие здесь могут быть плюсы и минусы? 

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

(00:30:03)

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

Но есть важное отличие. Собственно, важных отличий очень много, и я о них дальше в подробностях расскажу, насколько я мог их сформулировать. Возможно, вы меня дополните или исправите в комментариях или в чате, или где-нибудь. Но мне кажется, очень важно понимать различие, что Bitcoin и уровень peer-to-peer Bitcoin – это некоторая часть цельной системы (часть, собственно, Bitcoin), которая задумана для того, чтобы выполнять конкретную функцию, а именно моделировать деньги. В отличие от этого, BitTorrent, он агностик, ему всё равно, какой контент по нему передаётся, будь это музыка, фильмы, текстовые файлы, исполняемые файлы – всё что угодно, просто какой-то зашифрованный мусор. BitTorrent совершенно всё равно. Просто есть некоторые хеши контента, есть треккер, который меня адресует к узлам, или есть magnet-ссылка, есть какой-нибудь DHT, и семантика тех данных, которые распространяются по BitTorrent, она полностью отделена от BitTorrent-протокола. BitTorrent-протокол универсальный. И в отличие от этого, Bitcoin P2P-протокол, он абсолютно не универсальный. Он заточен и должен быть заточен под конкретную задачу – не распространения каких-то данных вообще, а распространения данных конкретно для обеспечения работы биткоина, и эти данные все имеют определённый смысл и связаны между собой и с другими участками этой системы определённым образом. Так что, хотя общая постановка задачи может выглядеть похожей. есть много важных отличий, и мне хотелось бы дальше по этим отличиям пройтись и про них поговорить.

Первое отличие заключается в следующем (как мне кажется, оно очень важно): блокчейн – это некоторый общий набор данных, некоторый общий dataset; в BitTorrent один из аспектов этой прекрасной децентрализации, которая позволила ему быть настолько устойчивым к атакам, это то, что на самом деле нет никакого определенного набора файлов, некоторого “the file”, который нужно с помощью BitTorrent распространять. Это просто некоторый протокол: если я хочу выложить какой-то файл – я его выкладываю; если кто-то хочет его скачать – кто-то его у меня качает. Нет никакой задачи, чтобы всех участников протокола вообще синхронизировать к какому-то единому состоянию. Каждый, в общем-то, качает, кто во что горазд, качает, что хочет, и нет никакого центрального набора данных. В Bitcoin, в отличие от этого, такой набор есть. Это, собственно, блокчейн, это набор блоков подтвержденных, и нам важно, чтобы все участники протокола пришли к тому состоянию, что у них есть полностью актуальный блокчейн. Так что это очень большое различие. 

Другое различие, что в скачивании файла через BitTorrent есть начало и конец. То есть, я хочу скачать файл, я начинаю его качать, вот он полностью докачался, и моя задача на этом выполнена, как бы мои полномочия на этом всё, исчерпаны. А блокчейн никогда не заканчивается. То есть, если у меня работает full node, то мне нужно постоянно синхронизироваться, мне нужно постоянно быть UpToDate, и эта задача как бы навсегда. И здесь тоже нужно это иметь в виду при дизайне P2P-слоя.

Ну и, конечно, Bootstrap. В Bitcoin, в отличие от BitTorrent, есть два режима работы (я про это чуть-чуть позже поговорю). Один режим работы – это такая постоянная синхронизация. Если у меня уже есть синхронизированный узел, то мне нужно просто поддерживать его в обновленном состоянии, раз в 10 минут синхронизируя очередной блок (в среднем 10 минут). Если я присоединяюсь к сети как новый участник, мне нужно сделать initial blockchain download (или IBD), то есть скачать все блоки за всю историю, их провалидировать и сохранить в структуру данных у себя. То есть, это несколько другая задача, которая несколько больше похожа на задачу скачивания файла через торрент, но всё равно в конечном итоге это выливается в то состояние, где вот у меня есть полностью обновленный узел, и дальше я его поддерживаю в обновлённом состоянии.

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

(00:35:00)

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

В свете этого, кстати говоря, интересно было бы вспомнить про статью, которую я разбирал в каком-то выпуске, а именно в выпуске №23, где рассматривались eclipse-атаки на Ethereum. Там эта статья, насколько я помню, получила потом развитие, и… Возможно, это была уже и другая статья. Я одну из свежих статей на эту тему пришлю опять-таки в шоуноты. По очень интересному совпадению её написала в значительной степени та же самая группа исследователей из Берлина, которую я уже упоминал раньше, и, собственно, идея там заключалась в том, что Ethereum, в отличие от Bitcoin, пытается переиспользовать Kademlia для обмена блоками. И выяснилось, что можно как-то заабьюзить систему. Собственно говоря, можно заабьюзить тот факт, что в файлообменных сетях нет устойчивости к sibyl-атакам, то есть можно нагенерировать множество айдишников, и дальше логика Ethereum в обращении с этими айдишниками была несколько небезопасным образом реализована. 

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

Я, кстати говоря, не знаю, как у них сейчас устроен peer-to-peer уровень. Насколько я помню из докладов на конференции Web3 Summit, куда мы ездили, с Сашей Селезнёвым мы ее освещали в большом количестве видосов, которые я с удовольствием пересматриваю в наши карантинные дни, когда никуда ездить нельзя, и вспоминаю, как мы классно там провели время. Из тех докладов я помню, что там есть какая-то довольно монструозная конструкция именно на сетевом уровне, разрабатываемая внутри Ethereum, около Ethereum и под эгидой Ethereum. Но тут не могу больше деталей вам предоставить.

Следующий пункт, который я хочу обсудить в серии пунктов, чем файлшеринг не похож на задачу обмена блоками в блокчейне, это то, что данные имеют некоторую логическую структуру. Вот я раньше уже сказал, что BitTorrent всё равно, какого формата данными вы обмениваетесь в нём. Хотите – фильмы качайте, а хотите – пиратскую Windows XP. Всё что угодно. В отличие от этого, блокчейн, который мы пытаемся синхронизировать, у него есть внутренняя логика и внутренняя структура, а именно, что блоки (опять-таки это, наверное, не станет ни для кого сюрпризом) организованы в цепочку, и валидность следующих блоков зависит от валидности предыдущих. А ещё у блоков есть заголовок, в который прикрепляется Proof-of-Work. И хорошо бы его проверять. Когда вы скачиваете блок, нужно проверить, что там Proof-of-Work соответствует уровню сложности для этого блока, который нужно проверять. Конечно, это не гарантия, что этот блок будет единственный, который удовлетворяет такому уровню сложности, но это минимальная проверка, видимо, которую нужно сделать.

И кроме того, из тех типов сообщений, которыми Bitcoin-узлы обмениваются на peer-to-peer уровне, и теми данными, которые они пытаются синхронизировать, здесь, мне кажется, можно разделить на 2 фундаментальных типа этих данных: это блоки, с одной стороны, а с другой стороны, это транзакции, ну и, в общем-то, всё остальное (сообщения типа, какие узлы присоединились, отсоединились, IP-адреса узлов и прочие служебные сообщения). 

Первая категория – блоки – это некоторый канонический dataset, который мы пытаемся синхронизировать. У него есть внутренняя логическая последовательность, у него есть то свойство, что в конечном итоге все должны им обладать и все должны его скачать, и это в какой-то степени похоже на задачу синхронизации файла через BitTorrent, хотя не совсем. Да, вот то, о чем я раньше уже сказал: нужно этот dataset поддерживать в реалтайме, он никогда не заканчивается. И здесь ещё интересные возникают требования относительно latency, относительно того, насколько быстро нужны эти блоки синхронизировать. Опять-таки, сравнивая с ситуацией, когда я просто качаю фильм с торрентов, ну мне хочется, конечно, чтобы он побыстрее закачался, но у меня нет каких-то прям вот жестких требований, что нужно это секунда в секунду, как можно быстрее. А для блоков такая мотивация есть, поскольку у нас есть майнеры, бизнес которых зависит от того, насколько быстро они смогут свой блок подтвердить в качестве правильного, насколько быстро последний правильный блок к ним придёт и они могут начать майнить на наем. Это всё очень важно. 

(00:40:18)

Конечно, у нас есть selfish mining, который я уже упоминал, и, возможно, там мотивация не настолько прозрачная и не настолько чистая, как это, возможно, предвидел Сатоши, описывал Сатоши в изначальном вайт пейпере, но тем не менее, всё-таки для майнера важно иметь быстрое соединение и важно получать блоки сразу. Потом он может, наверное, принять какое-то решение делать selfish mining и отказаться бродкастить свой блог, но, конечно, майнеру хотелось бы, чтобы у него была техническая возможность получать блоки как можно быстрее, и именно поэтому между майнерами натянуты специальные сети, через которые прогоняются блоки очень быстро. Это выделенные каналы, которые проходят вне обычных интернет-сетей, то есть такое сложно себе торренте представить. Какая может быть задача синхронизации через BitTorrent, чтобы было оправдано и чтобы кто-то заморочился и потратил, наверное, значительное количество денег на то, чтобы понять отдельно выделенные ультрабыстрые каналы, чтобы синхронизировать какие-нибудь экранки последнего голливудского блокбастера с миллисекундной точностью.

Это то, что касается блоков, то есть это такой некоторый набор данных, которым все должны обладать. Но ещё у нас есть вспомогательные сообщения, в том числе транзакции, и здесь синхронизация происходит менее строго, и у нас нет такого единого источника истины, то есть нет некоторого набора транзакций, нет некоторого мемпула с определенным артиклем (the mempool), нет такого, что нужно этот the mempool синхронизировать. Просто разные участники сети, разные ноды подхватывают разные транзакции и формируют у себя какой-то пул неподтвержденных транзакций, из которых они, если они майнеры, могут выбирать отдельные транзакции, формировать блоки, применять какие-то свои эвристики, выбирать транзакции с максимальной комиссией и так далее, и так далее. При этом, если какая-то отдельная транзакция до кого-то не дойдет, ну, в принципе, небольшая беда. Так что это несколько другой способ синхронизации, другой тип задач, которые мы здесь решаем. То есть, нам хотелось бы, конечно, чтобы транзакции как можно быстрее распространялись по сети, но всё-таки здесь, скажем так, если мы исходим из предположения, что транзакции без подтверждений всё равно не безопасны и zero confirmation всё равно принимать не нужно в оплату сколько-нибудь значимых товаров и услуг, значит, всё равно нужно ждать, пока не появится хотя бы один блок. А если мы ждём всё равно как минимум 10 минут, то плюс-минус несколько секунд latency не сыграют большой роли. Если транзакция где-то зависнет на пару секунд, то это не страшно.

Сравните это с предыдущими требованиями к propagation блоков, где как раз несколько секунд – это какой-то ощутимый процент (там доли процента, конечно), но если это умножить на награду за блок, то там прям можно, наверное, какое-то простое деление и посмотреть, сколько долларов в секунду утекает с каждой следующей секундой, пока распространение блока тупит.

Кроме того, у транзакции есть тоже некоторая семантика, есть такая вещь, как верификация, то есть по крайней мере bitcoin-core, он не распространяет транзакции, которые не валидные, то есть перед тем как что-то передать дальше, это еще как бы проверь, на самом деле стоит ли дальше посылать или нет. И в Bitcoin это может быть ещё и просто, потому что проверка подписи – это относительно дешевая операция, насколько я представляю. В случае если мы идём в другие блокчейны, такие как Ethereum, со своими смарт-контрактами, с более сложной механикой, где нужно не просто провалидировать транзакцию, а выполнить некоторый код, который будет вызывать какие-то другие участки блокчейна, более сложные операции. Это тоже всё накладывается на общую задачу распространения информации по сети. Если мы хотим не нагружать сеть невалидными транзакциями, если мы не хотим открывать такое окно для DDoS-атак, где злоумышленник мог бы просто зафлудить сеть какими-то абсолютно невалидными сообщениями, если бы никто их не проверял, то они бы просто всю сеть заполонили и остановили. Надо, конечно, проверять, что транзакции валидные, прежде чем переправлять их дальше. А это дополнительные затраты на время, что тоже вносит свой вклад в скорость распространения и вообще во всю эту формулировку задачи. То есть, при дизайне таких систем, как мне представляется, нужно на это обращать внимание и как-то это просчитывать.

Ну да, как было сказано раньше, latency в случае распространения транзакций, наверное, не играет такой уж важной роли. Тем более, там всякие служебные сообщения типа «вот такой-то узел появился в сети, у него такой-то IP-адрес». Тоже, наверное, не будет ничего уж такого страшного, если кто-то это сообщение потеряет или если оно на сколько-то секунд где-то зависнет. Наверное, сеть такое переживёт.

(00:45:05)

Также мне кажется интересным, продолжая сравнение BitTorrent и Bitcoin, что в Bitcoin довольно чётко, как мне кажется, разделяются две роли, а в BitTorrent тоже как бы есть две роли изначально, но они довольно быстро сливаются в одну.

Для начала про BitTorrent скажу. В BitTorrent всё-таки есть некоторое разделение по тому принципу, что изначально у кого-то одного новый файл есть, а больше ни у кого этого файла нет. То есть, есть вот сидер, который этот файл сидирует, то есть распространяет, а есть личеры, которые присосались, как присоски (забыл перевод этого слова – личеры) пиявки, наверное, присосались к этому сидеру и пытаются файл вытянуть. Но поскольку протокол построен таким образом, что как только некоторый кусочек файла у меня скачан, я уже начинаю его раздавать, то, собственно, мгновенно все личеры становятся такими на 1% сидерами, на 5% сидерами и так далее, то есть эти роли смешиваются, и, с точки зрения меня, если я подключаюсь к некоторому набору пиров, которые обмениваются одним файлом, мне, в принципе, не важно, качаю ли я куски файла у того, кто изначально его выложил, либо у того, кто его скачал позже, либо у того, кто сейчас его качает, но пока ещё не докачал. В общем, тут роли смешиваются очень быстро, опять-таки в рамках одного swarm, в рамках одного роя, который качает один и тот же файл.

В Bitcoin же, хотя изначальный дизайн (собственно, и дизайн в настоящий момент) не предполагает какого-то разделения на уровне протокола, никаких у нас нет выделенных супернодов, мастер-нодов и так далее, всё-таки у нас есть майнеры и не майнеры. И мне кажется, что это довольно важное разделение, потому что у майнеров всё-таки есть экономическая мотивация явная – они на этом зарабатывают, и, по сути, только майнеры беспокоятся о том, чтобы получать транзакции не подтвержденные, те, которые ещё не вошли в блок, потому что, собственно, майнеры их в блоки включают и получают комиссию, которая в эти транзакции включается. Если обычные пользователи, не майнеры, им интересно состояние балансов, мне интересно, пришли мне деньги, например, или нет, я это смогу с уверенностью сказать, только когда появится хотя бы один блок, который будет подтверждать интересующую меня транзакцию. Поэтому, в принципе, что проходит в сети, что у кого находится в мемпуле, меня не должно особо волновать. А майнера это должно волновать. Майнеру важно не упустить наиболее жирные, наиболее такие интересные транзакции с точки зрения комиссии.

Ну и опять-таки, как я упоминал уже раньше, майнеры (я бы даже сказал, только майнеры) беспокоятся о скорости распространения блоков прямо с точностью до секунды, потому что им важно не потерять прибыль, и им также важно свой блок, если майнер нашел блок, его протолкнуть к другим майнерам, чтобы другие майнеры поскорее его признали как правильный и стали на нём майнить, а не на чём-нибудь другом. В отличие от майнеров, узлы, которые не майнят, им не так важно получать транзакции в реальном времени, им даже не так важно получать блоки прям в реальном времени, потому что, по сравнению с временем между блоками, а это 10 минут в среднем, а иногда бывают задержки по 20 и по 30 минут, и больше, наверное, можно там в какую-то формулу вставить эти параметры и посчитать вероятность, сколько там можно ожидать в день тридцатиминутных окон между блоками, шестидесятиминутных окон между блоками и так далее, то есть бывает очень долго.

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

Ещё я хотел бы поговорить про вопрос мотивации и про вопрос приватности, который, мне кажется, здесь несколько смежен с вопросом мотивации. Интересный fun fact состоит в том, что полные узлы никак не вознаграждаются просто за то, что они полные узлы. Предполагается, что участники протокола Bitcoin хотят поддерживать полные узлы, потому что это приносит им некоторое преимущество, это приносит им возможность независимо, самостоятельно валидировать состояние блокчейна и состояние транзакций, которые им интересны, и это позволяет им пользоваться протоколом, никому не доверяя не только в смысле доступности (availability) сервиса, но и в смысле приватности. То есть, если я хочу узнать сколько денег на моих адресах, я никому не должен раскрывать эти адреса (так что кто-то за мной в таком случае сможет шпионить и прослеживать мои будущие транзакции), а я просто синхронизирую все адреса, и уже локально, внутри своего софта, я отфильтровываю те, которые мне интересны.

(00:50:03)

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

Я даже не уверен, что это, в принципе, теоретически возможно, потому что полный узел – собственно, что такое полный? Это узел, который распространяет транзакции по сети, то есть это некоторый провайдер сетевых услуг, провайдер bandwidth and storage, то есть он хранит блокчейн, и он этот блокчейн раздает всем желающим. И хотя уже несколько лет ведутся разработки (такие проекты, как Filecoin, такие проекты, как Storj и прочие блокчейн и около блокчейн-проекты, которые пытаются приделать экономическую мотивацию к сервису хранения данных, для этого, конечно, нужно придумать математический, криптографический механизм, как проверять, что те данные, которые кто-то обещал мне сохранить (а я ему денег заплатил), действительно он сохраняет эти данные. 

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

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

Первое – читать блокчейн. Я хочу, чтобы мои пиры, чтобы мои соседи в сети, мне предоставляли полную истинную информацию о том, какое сейчас состояние Bitcoin-вселенной, у кого на самом деле сейчас сколько денег и к какому консенсусу пришла сеть относительно балансов всех участников и всего множества не потраченных UTXO. 

Это в значительной степени, конечно, достигается с помощью Proof-of-Work, и даже если полностью я окружен злонамеренными узлами, всё равно, чтобы подменить блокчейн, им нужно переделывать Proof-of-Work. Если предположить, что всё-таки у меня есть правильное представление о том, какого порядка сейчас сложность в сети, и меня так просто, значит, не обманешь хешем, который начинаться будет с одного нуля или с двух нулей, а не с 70-ти или сколько там нужно нулей сейчас в начале, если предположить это, то Proof-of-Work как раз очень хорошо решает проблему того, что я хочу читать блокчейн.

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

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

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

(00:55:08)

И поскольку те моменты, когда новые блоки появляются, они публично доступны, то можно провести нехитрый, видимо, статистический анализ и понять, что это загадочное приложение, которое обменивается какими-то зашифрованными данными — на самом деле это биткоин-узел. Но как бы то ни было, очень сложно простого пользователя на 100% отрезать от сети. Если у него есть какой-то доступ к Интернету, то, наверное, эту транзакцию можно будет протолкнуть, тем более, что есть просто онлайн-сервисы (в какой-то момент Blockchain.info предоставлял такой сервис; сейчас, по-моему, они этого не делают, но наверняка делает кто-то другой), просто такая формочка на сайте «Скопипастите сюда свою подписанную транзакцию в шестнадцатеричном виде, – или в каком-нибудь виде, – а мы её просто за вас отправим в сеть». Такие сервисы наверняка есть. Так что цензуру тоже довольно сложно осуществить.

Но третий пункт, к которому я сейчас постепенно прихожу логически –это приватность, и здесь как раз всё гораздо хитрее и гораздо сложнее. По идее, приватность – это очень важное качество не только даже потому, что мы просто из соображений и из-за желания какого-то психологического комфорта нам не нравится, когда нам заглядывают через плечо, нам не нравится, когда за нами наблюдают. Это, понятно, вызывает просто психологический дискомфорт. Но кроме того, даже чисто функционально и чисто так утилитарно для денег это необходимые качества из-за fungibility, из-за требования взаимозаменяемости единиц криптовалюты и вообще валюты. Всё-таки нам хочется, чтобы система денег обладала тем свойством, что каждая единица этих денег равна каждой другой единице, иначе нам придется на каждого участника экономических взаимодействий взваливать этот груз анализа своих входящих транзакций и применения некоторого дискаунта, например, вот эти купюры, вот эту стодолларовую купюру: она у вас чем-то запачканная, и я ее приму за 80 долларов, а вот эту я приму за 96 долларов. Если довести это до абсурда, если довести это до логического завершения, то получится, что все экономические агенты будут тратить если не все свои усилия, то большое количество своих усилий на то, чтобы просто применять эти дисконты в каждой транзакции, которую они получают и отправляют, что просто неразумно. Зачем это делать, если мы можем спроектировать систему так, что просто все договорились, что каждый доллар равен доллару и каждый биткоин равен биткоину, и мы просто живем спокойно и направляем наши усилия на более важные и нужные занятия. 

И здесь эта задача мне кажется очень важной, и если мы опять-таки вернёмся к этому сравнению, которое я провожу через весь этот выпуск – «BitTorrent против Bitcoin» или «BitTorrent в соотнесении с Bitcoin» – BitTorrent защищает приватность на самом деле плохо, и опять-таки, возможно, это задача даже не так критично стоит для файлообмена, несмотря на то, что, конечно, мы слышали все про судебные процессы и про то, что в некоторых странах (особенно в Германии, например) любят и могут, и делают это – отслеживают пользователей торрента по трафику на уровне  провайдеров, присылают им письма, и если пользователь не прекращает качать файлы через торренты, то могут их оштрафовать. Не знаю, тюремное заключение предусмотрено для этого или нет, но по крайней мере можно нарваться на большой штраф и неприятности с Интернет-провайдером. Но далеко не все так делают, и, как показывает практика, у большинства, на самом деле, недостаточно есть просто дела для того, чтобы это енфорсить. И хотя это формально нелегально, я думаю, в подавляющем большинстве стран оно продолжает движение, эта тусовка продолжает развиваться. 

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

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

(01:00:02)

Конечно, мы хотели бы, чтобы такого не было и чтобы просто на уровне протокола такую информацию нельзя было бы получить. 

Надо сказать, что уровень приложения (application layer) в Bitcoin тоже защищен так себе. У нас весь граф транзакций открыт, и несмотря на то, что есть миксеры, несмотря на то, что есть тот же Lightning Network, который какую-никакую обеспечивает обфускацию, хотя там другие проблемы с приватностью возникают, и несмотря на то, что Bitcoin можно через Tor запускать, всё равно всё это не обеспечивает стопроцентной защиты и стопроцентной приватности, а только нас как-то приближает к этому идеалу, возможно, не так быстро, как нам хотелось бы.

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

Одно направление атаки – это окружить меня полностью злонамеренными узлами, то есть произвести эклипс-атаку. Уже выше я про это упоминал. На самом деле, возможности такого злоумышленника довольно ограничены в плане того, что он вряд ли может мне подсунуть фальшивый блокчейн и ему сложно запретить мне постить транзакции, потому что я могу это сделать, в принципе, и в обход соединения с P2P-сетью биткоина вообще, через какие-то сторонние сервисы. Но тогда, всё-таки если я подвержен полной эклипс-атаке (и даже частичной эклипс-атаке), то злоумышленник может мои транзакции отслеживать и пытаться сопоставить их с моим IP-адресом, пытаться сопоставить мои транзакции между собой и дальше отслеживать их судьбу, уже опираясь на открытую информацию, на блокчейн и, возможно, на какие-то другие данные. То есть, это такой локальный уровень атаки – окружить меня злонамеренными узлами.

С этим борется Bitcoin, и тут надо сказать, что разработчики внимательно к этому относятся. Есть специальные меры, для того чтобы обеспечить разнообразие этих коннекшенов. Bitcoin будет стараться не подключаться к узлам, у которых IP-адреса имеют общий префикс, то есть подключиться через только одну подсеть не удастся, так как это енфорсится на уровне протокола, в смысле на уровне имплементации Bitcoin Core, енфорсится некоторое биографическое и некоторое, скорее всего, административное разнообразие просто через IP-адреса тех узлов, к которым я подсоединяюсь. И есть механизм рандомизации бродкастинга транзакций, есть механизм какой-то… Вот ротации – я не уверен, но в любом случае здесь я хотел бы подчеркнуть различие этой задачи с задачей BitTorrent, где есть оптимизация, которая, наоборот, направлена на то, чтобы те пиры, с которых я качаю файл, были как можно ближе ко мне, были как можно локальнее. В идеале там есть такой механизм, который называется ретрекинг. Вот я здесь уже не очень понимаю детали, но идея состоит в том, что я подключаюсь к пирам не просто из большого Интернета, а я подключаюсь к пирам конкретно из моего провайдера, возможно, даже из моего района, из моего дома, и разумеется, у меня локальное соединение быстрее, чем если бы это проходило через большой Интернет, поэтому у меня скачиваются файлы быстрее.

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

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

(01:05:24)

Это такой глобальный подход. То есть, есть вот локальный подход, локальные атаки на приватность и глобальные атаки на приватность. 

И здесь, собственно, я ставлю многоточие, ставлю точку с запятой. Здесь, видимо, эта вступительная глава закончится, и дальше начнутся уже в моей диссертации описания, собственно, моих контрибьюшенов, потому что они тоже в каком-то смысле, по крайней мере вот эта часть, посвящённая сетевому уровню биткоина, её можно разделить на эти две части. То есть, некоторый есть у меня research, который посвящен локальным вещам, то есть у меня есть некоторое исследование того, насколько кошельки безопасным и приватным образом распространяют транзакции от пользователей, и выясняется, что большинство кошельков на самом деле так не делают, большинство кошельков просто соединяются к какому-то серверу, и этот сервер уже бродкастит мои транзакции в сеть. В этом смысле большинство, по крайней мере по состоянию на сентябрь 2018 года, когда я делал это исследование, большинство мобильных кошельков, они просто эклипсят своих пользователей по умолчанию. Что они там отслеживают, можно только догадываться. 

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

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

Большое спасибо за внимание. Я говорю «спасибо» всем, кто дослушал до конца. Подписывайтесь на нас везде. Мы называемся Basic Block Radio. У нас есть сайт basicblockradio.com, мы есть во всех социальных сетях, особенно мы активны в Телеграмме. Там есть такой чат, называется «ББ-чат». Там и гости, и постоянные слушатели, и непостоянные слушатели подкаста «Базовый блок» вступают в крайне интересные и продуктивные дискуссии относительно блокчейн-технологий. Так что вступайте туда, пожалуйста.

Спасибо огромное нашим спонсорам. Нас поддерживает Hodl Hodl – самый быстрый, безопасный и дешевый способ купить биткоины и продать биткоины без верификации. Специальная ссылка в описании – регистрируйтесь. 

Мы благодарим Zerion – простой и приятный интерфейс к миру DeFi. Слушайте подкасты с ребятами из Zerion. У нас на самом деле, мне кажется, практически все из их, скажем так, ключевого состава были в гостях: и Алексей, и Вадим, и Евгений. У нас были в недавних выпусках, послушайте про них, они эксперты в DeFi самого высокого класса. 

И Solana – новый наш спонсор. Быстрый блокчейн без шардинга, 60 тысяч транзакций в секунду, блоки раз в 400 миллисекунд – просто фантастика. Заходите в Telegram Solana RUS. Они готовы отвечать на все ваши вопросы.

Рассказывайте про подкаст друзьям. Лайк, шер и ретвит, ББ-чат, Патреон. До следующего выпуска! Счастливо!

Добавить комментарий