Биткойн в 2021 году

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

В начале прошлого года я написал статью, в которой рассуждал о своих общих приоритетах по Биткойну, и я по-прежнему вполне доволен таким подходом – средство сбережения как основа определённо оправдало себя!

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

Тем не менее я не уверен, что в этом году буду настроен на рост биткойна; скорее я ожидаю консолидацию. Взгляните, какой была цена BTC в начале последних нескольких лет: $450 в 2016 г., $1000 в 2017 г., $13 000 в 2018 г., $3700 в 2019 г., $8000 в 2020 г., и вплоть до $55 000 в 2021 г. Был ли в 2016-18 гг. восьмикратный рост обеспечения и надёжности, который бы соответствовал росту цены с января 2016 г. по январь 2019 г. в 8 раз? Возможно, да. Был ли восьмикратный рост обеспечения и надёжности в 2019-20 гг., который бы соответствовал росту цены ещё в 8 раз? Возможно. Но что, если кто-то думает о достижении цены $200 000 или $300 000 в ближайшем будущем, – не требуется ли для этого рост обеспечения и надёжности ещё в 8 раз? Откуда он возьмётся? И эти коэффициенты умножаются: если вы хотите $280 тыс. в декабре 2021 г., то это рост надёжности не в 3*8 = 24 раза, в 8 в кубе = 512 раз за шесть лет (2016-22 гг.)! Ваши оценки могут варьироваться, но я не думаю, что Биткойн уже в 500 раз надёжнее, чем 5 лет назад.

Поэтому, как бы я ни был воодушевлён в связи с Taproot и возможностями, которые он открывает (PTLC и в дальнейшем eltoo в сети Lightning, «сценарии без сценариев» и discreet log-контракты, доказательство резервов, сохраняющее конфиденциальность, дешёвые мультиподписи – возможно, список не бесконечный, но как минимум очень длинный), пожалуй, я теперь ещё больше, чем год назад, придерживаюсь мнения, что важнее работать над тем, что укрепляет существующий фундамент, чем над красивыми новыми идеями, которые его меняют.

Уже есть ряд направлений, где подход Биткойна к безопасности и надёжности за последние несколько лет улучшился в техническом плане: больше людей занимаются рецензированием (например, через клуб рецензирования запросов на включение изменений или программу стажировки Chaincode), непрерывное интеграционное тестирование стало более глубоким и разнообразным (как благодаря тому, что стало возможно больше интеграций через GitHub, так и из-за того, что Travis стал настолько ненадёжным, чтобы заставить искать другие подходы), фаззинг-тестирование значительно улучшилось и стало несколько шире использоваться, и, на мой взгляд, статический анализ кодовой базы немного усовершенствовался. Также был ряд улучшений стандартов кода (например, использование безопасных указателей, аннотаций блокировки, класса span вместо сырых указателей). Я не проводил анализ, но это то, что мне подсказывает память и интуиция.

Что касается надёжности, на мой взгляд, краткосрочные приоритеты следующие:

1. Модуляризация – например, чтобы можно было лучше разделить процессы, чтобы снизить риски для безопасности, и лучше использовать фаззинг, чтобы отловить баги в пограничных случаях. Уже ведётся работа над тем, чтобы разделить графический интерфейс пользователя и кошелёк на отдельные процессы, но пока этого нет в стандартной сборке. Если интерфейс P2P-сети также будет отдельным процессом, это может быть ещё одним преимуществом. Хотя это привлекательная цель, думаю, до LibConsensus ещё далеко – P2P, управление пулом памяти и правила валидации сейчас достаточно тесно переплетены, – но можно предпринять шаги к этой цели, которые сами по себе будут улучшениями.
2. P2P-сеть – это очевидный способ атаковать Биткойн, поскольку, по определению, доступ имеет каждый. Здесь есть несколько уровней: пассивный мониторинг P2P-сети может позволить нарушить ожидания пользователей насчёт конфиденциальности, тогда как активная изоляция пользователей в независимые сети может разрушить фундаментальные предпосылки Биткойна (невозможно продлить самую длинную цепочку, если нельзя контактировать с теми, у кого она есть). Есть также целый ряд промежуточных проблем между этими крайностями, которые, например, могут нарушить предпосылки систем второго уровня, таких как Lightning. Сторонние (потенциально централизованные) альтернативы как резервные копии P2P-сети также могут предоставить ценную поддержку – нечто вроде Blockstream Satellite, передачи блоков по любительскому радио или передачи заголовков блоков через DNS может исправить расколы в P2P-сети, которые сам P2P-уровень не может автоматически устранить. Или же улучшения эффективности, такие как Erlay или подключение только для передачи блоков, сделают возможным более высокое качество связи, что усложнит атаки.
3. Непрерывная интеграция, статический анализ, воспроизводимые сборки – за последний год, похоже, платформа Travis превратилась из периодически имеющей назойливые проблемы в практически непригодную для проектов с открытым кодом. Непрерывная интеграция – важная часть разработки и рецензирования; её нарушение существенно усложняет и то, и другое. То, что мы имеем сейчас, кажется весьма неплохим, но оно ещё ново и пока недостаточно проверено временем, так что, пожалуй, понадобится год на доработки. Думаю, требуют совершенствования и другие аспекты, связанные с непрерывной интеграцией, например автоматизированное тестирование первичного скачивания блоков (похоже, данные на bitcoinperf устарели на несколько месяцев). Статический анализ служит похожей цели, и хотя многое уже включено в непрерывную интеграцию через линтеры и опции компиляторов, думаю, здесь возможна ещё дополнительная полезная автоматизация. Наконец, всегда ценно уделить внимание «последней мили», чтобы убедиться, что люди используют ПО, которое тестируют разработчики, и, кажется, работа с NixOS подаёт надежды в этом плане.
4. Валидация третьими сторонами – в последнее время появился ряд инструментов для стороннего мониторинга: различные сайты, отслеживающие комиссии и размер пула памяти; ForkMonitor, ищущий тупиковые блоки (и двойное расходование); или, с натяжкой, анализ поведения кошельков и поддержки SegWit от Optech.

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

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

Есть также другие уровни надёжности и безопасности, помимо просто поддержания работы сети, если рассмотреть вопрос «как предотвратить потерю/хищение моих монет?» шире. Фишинг и потенциальные физические атаки в результате утечки данных кошелька Ledger – это простые примеры такого рода проблем, но взломы/сбои бирж вообще, вредоносное ПО, подменяющее адреса, так что ваши средства идут злоумышленникам вместо нужного получателя, и потеря доступа к ключам – это также повод для беспокойства. Думаю, дескрипторы, Miniscript и мультиподписи Taproot станут хорошим шагом к тому, чтобы предотвратить потерю ключей, а прогресс с BIP322 (подписание сообщений по адресу Биткойна) может помочь избежать атак с подменой адреса.

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

Очевидно, что там, где это возможно, подобные стандарты должны внедряться посредством аудируемого открытого кода, вместо того чтобы требовать больших средств на реализацию от каждой компании. Но также стоит подумать о том, могут ли такого рода нормативы принять вид отраслевых стандартов («мы придерживаемся отраслевых стандартов, тогда как конкурент X – нет») вместо обязательного правительственного регулирования – среди прочего, вызывает сомнения, имеют ли правительственные регуляторы нужный опыт, чтобы выбрать оптимальные практики, которых должны придерживаться криптовалютные системы. Хотя, возможно, это должно быть нечто ориентированное на «права потребителей», а не на «отрасль» как таковую, чтобы это не было лишь вектором для регуляторного захвата.

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

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

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

Я также общался с Джереми Рубином, у которого есть интересные идеи о финансировании для Judica. Опять же, если я правильно понимаю, суть предложения в том, чтобы попытаться объединить благотворительную/покровительственную модель, финансирующую многие разработки с открытым кодом в Биткойне, с подходом ангельского инвестирования, что может принести больше средств на начальном этапе благодаря реалистичной возможности получить в итоге прибыльный бизнес и, следовательно, окупить начальные вложения.

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

(Есть также много интересных экспериментов с финансированием в сфере децентрализованных финансов/Эфириума вообще, но пока что я не думаю, что они способствуют текущему финансированию разработок по надёжности и безопасности, о котором я здесь говорю.)

Пожалуй, есть три «атаки», которые меня в настоящее время беспокоят, и все они связаны с вышеописанными совершенствованиями.

Первая из них связана с тем, что «модуляризация», о которой говорилось ранее, подразумевает много манипуляций с кодом, причём так, чтобы не изменить какое-либо поведение. Но поскольку меняемый код сложный, можно запросто изменить поведение случайно, потенциально создав досадные баги или даже уязвимости. А поскольку рецензенты не ожидают изменений поведения, эти проблемы может быть сложно выявить. Пожалуй, это напоминает проблемы с беспилотными автомобилями или контрольным досмотром – большую часть времени всё хорошо, поэтому сложно гарантировать сохранение полной бдительности, чтобы справиться с теми редкими случаями, когда что-то пойдёт не так. И хотя есть много автоматизированных проверок, которые выявляют различные классы ошибок, они всё же далеко не идеальны. Мне кажется, что здесь есть серьёзные риски как случайных багов, так и намеренных уязвимостей, вставленных злоумышленниками, которые могут какое-то время выдавать себя за контрибьюторов Биткойна. Но даже несмотря на эти риски, модуляризация всё равно кажется стоящей целью, так что вопрос в том, как лучше всего эти риски минимизировать. К сожалению, помимо того, что уже делается, я не знаю, как этого можно достичь. Я пытался использовать вопрос «действительно ли это изменение является преимуществом?», чтобы ограничить скорость изменения кода, но пока не добился результата.

Ещё один потенциальный вектор атаки – это рецензирование кода. Это важная часть поддержания корректности и безопасности Биткойна, которая не слишком хорошо масштабируется. Этому есть несколько причин: самая простая из них – это то, что один человек может за день вычитать ограниченный объём кода, но ещё один фактор – это то, что любой патч может иметь незаметные последствия, которые проявляются только при взаимодействии с другим кодом, который не меняется, и очень сложно знать обо всех потенциальных неочевидных взаимодействиях в базе кода, и даже если они известны, может потребоваться время, чтобы понять, к чему они могут привести. Таким образом, больше изменений – это одна проблема, но разделение рецензирования между большим числом людей – другая: это снижает вероятность, что патч с незаметным багом будет проверен тем, кто способен понять, что такой незаметный баг вообще существует. Точно так же быстрая и эффективная разработка – это не всегда преимущество: это сокращает время, доступное для того, чтобы понять, что есть проблема, до того как изменения будут внесены и люди сосредоточатся на чём-то другом. Модуляризация, по крайней мере, здесь помогает: она существенно снижает вероятность взаимодействий с совершенно другими частями проекта, но, конечно, не исключает её полностью. Непрерывная интеграция также помогает, автоматизируя рецензирование классов потенциальных проблем. Думаю, мы уже неплохо справляемся в этом плане с консенсусным кодом: есть много рецензий, и всё продвигается неспешно. Но другие направления вызывают у меня беспокойство. Например, я очень удивился, увидев, что запрос на включение изменений №20624 был предложен в пятницу и принят в понедельник (да ещё и в предрождественский период). Такие изменения запросто могут внести незаметные баги, которые могут серьёзно сказаться на P2P-взаимодействии, и я не думаю, что это такое важное улучшение, которое оправдывало бы подход «сначала включи, а рецензируй позже».

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

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

Один из рисков финансирования большей части разработки одним и тем же способом в том, что это способствует конформизму вместо разнообразия. Очевидное правило спонсирования – «не кусай руку, которая тебя кормит». Например, в соглашении о грантах разработчикам от BitMEX сказано: «Не предпринимать действий, которые могут нанести ущерб репутации грантодателя». И я не хочу это критиковать: это естественное следствие сущности гранта. Но если все, кто работает над Биткойном, будут непосредственно мотивированы придерживаться этого правила, то что будет, если понадобится сообщить о ненадлежащем поведении?

Конечно, возможно, здесь уже всё в порядке, потому что есть достаточно разработчиков, которые могут спокойно уйти с работы или которые уже настолько финансово независимы, чтобы ни перед кем не отчитываться?

Однако мне кажется тревожным звоночком то, что Люк Дашир не получил один из таких грантов, – я знаю, что он подавал заявку на несколько, и он обладает всеми необходимыми качествами: он долгосрочный контрибьютор, он сыграл важную роль в привлечении внимания к проблемам BIP16, в реализации SegWit, в предотвращении катастроф, которые могли возникнуть из-за активации софт-форка SegWit пользователями (UASF), и в работе над активацией Taproot, и он один из тех, кто хорошо умеет находить малозаметные взаимодействия, создающие риски багов и уязвимостей, о которых я говорил выше. С другой стороны, он известен своими чудаковатыми идеями, с ним может быть сложно работать и, возможно, его ожидания нереалистичны. И что же это даёт в сумме? Возможно, он представляет прецедент как раз такой атаки на Биткойн. А может, ему просто не везёт. Или же ему просто нужно лучше себя разрекламировать или сменить отношение на более благоприятное для бизнеса – и, думаю, как раз такое отношение необходимо, если хочешь решить проблему самостоятельно, вместо того чтобы полагаться на чью-то помощь.

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

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

Как бы то ни было, подведу итог

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

В остальном хотелось бы увидеть актуальные и пригодные для тестирования патчи ANYPREVOUT. Поскольку это открывает путь для eltoo, что улучшает надёжность каналов Lightning, это будет отличное достижение в плане безопасности (и я считаю, что в целом именно этого недостаёт Lightning, а следовательно, это также хорошо согласуется с целью роста Lightning такими же темпами, как Биткойн). Однако, пожалуй, приоритет этого не такой высокий, как улучшение надёжности базового уровня Биткойна.

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

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

Если вы по какой-то причине читаете это, чтобы найти советы касаемо того, что вам делать, а не чтобы узнать мои мысли, то вот, что мне приходит на ум:

• Деньги: подумайте насчёт того, чтобы (в восходящем порядке денежных сумм) поддержать или нанять Люка Дашира или других разработчиков Биткойна (или, если вам это по силам, самому что-то сделать), поддержать Инициативу по цифровым валютам МТИ или профинансировать/создать что-то независимое, но не менее хорошее, чем инициатива МТИ или Chaincode. Для банков, которых затронуло письмо Управления контролёра денежного обращения США о платежах, хорошей идеей будут серьёзные инвестиции в разработку Lightning.
• Код Биткойна: помогите улучшить внутренний тестовый охват, статический анализ и/или воспроизводимость сборок; организуйте и поддерживайте внешнее тестирование; рецензируйте код и ищите баги в запросах на включение изменений, прежде чем они будут одобрены. И есть ещё миллион интересных опций, над которыми можно работать.
• Lightning: поработайте с PTLC (используя Taproot в Signet или на основе ECDSA), ANYPREVOUT/eltoo, над улучшением предотвращения спама и вообще над реализацией и совершенствованием всего, что уже есть в списке текущих задач для Lightning.
• Другие проекты: проводите больше тестирования в Signet вообще, протестируйте интеграцию Taproot в Signet (особенно что касается опций безопасности, таких как мультиподписи), мониторьте активность в блокчейне и пуле памяти на предмет странностей, чтобы помочь максимально быстро обнаружить и предотвратить потенциальные атаки.

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

Источник

Вы всегда можете поблагодарить переводчика за проделанную работу:BTC: 3ECjCH5tPoyDCqHGCXfiiiLZQ3tVGzCSxBETH: 0xf45a9988c71363b717E48645A412D1eDa0342e7E