Этот тред (речь о треде в Твиттере — прим. перев.) дополняет тот, где я рассуждал о параметрах «количество транзакций в секунду» и «количество блоков в секунду», TPS/BPS. Основная причина, по которой я не стал тогда углубляться в тематику времени подтверждения — то, что «время подтверждения» суть концепция очень тонкая.
Дисклеймер: чтобы понять подтверждения, нужно увидеть, как они проявляются в разных технологиях. По этой причине я буду обсуждать типы подтверждений для различных проектов, таких как Биткойн (Bitcoin, $BTC), Кадена (Kadena, $KDA), Некса (Nexa, $NEXA), Хатор (Hathor, $HTR) и Йота (Iota, $MIOTA). Я призываю читателя не воспринимать дальнейшее академическое обсуждение как попытку очернить какую-либо технологию. Помните, что критика — двигатель изобретательности.
Основные выводы, которые я пытаюсь донести в этой теме:
В отличие от TPS/BPS, понятие «время подтверждения» субъективно.
Существует множество различных типов «подтверждений», и одни их формы слабее других.
Нет смысла сравнивать времена ожидания для разных типов подтверждений и игнорировать при этом предоставляемые ими гарантии.
От варианта слоя консенсуса зависят только сильные формы подтверждений. Более слабые формы реализованы поверх L1 и в значительной степени не зависят от них.
К сожалению, во многих технологиях интерфейс кошельков и прочего отображает транзакцию как «подтвержденную» преждевременно, вводя пользователей в заблуждение относительно того, как долго подтверждение достигается на самом деле.
Что ж, погрузимся.
Когда я говорю, что время подтверждения «субъективно», я имею в виду, что не существует обязательного правила, устанавливающего, когда транзакция считается «подтвержденной». Лучшее, что может предоставить любая из технологий — это гарантии того, насколько невыполнимо/дорого окажется откатить транзакцию. Различные получатели удовлетворятся разными типами безопасности. Например, многие продавцы не будут считать вашу биткойн-транзакцию полученной до того, как она «опустится» на глубину шести блоков, хотя некоторые согласятся и на четыре блока, а некоторые будут ждать целых десять. Дело в том, что они решают сами. «Время подтверждения» определяется степенью осторожности продавца.
Ну и какие же типы гарантий существуют? Есть целый зоопарк подходов и идей обеспечения гарантий безопасности, но я бы сказал, что большинство из них, если не все вообще, можно разделить на три типа, которые я ниже опишу и стану обсуждать в порядке убывания силы.
Самая сильная форма подтверждений называется обычно «детерминированной финальностью». По сути, это означает, что ничто, кроме хард-форка, не в состоянии отменить транзакцию. Этот тип подтверждения реализован, например, в системах PoS, где время разделено на раунды, и гарантируется, что транзакции из предыдущих раундов не могут быть отменены. Детерминированная финальность существует, впрочем, и в PoW: чтобы реализовать «обрезку» данных леджера, у нас должна быть гарантия, что достаточно старые транзакции зафиксированы. Эта гарантия позволяет нам отбрасывать данные о транзакциях, произошедших глубже определенной точки, и сохранять только набор UTXO, имеющихся на это время, и часть полноценного реестра некоторого фиксированного размера. В сценарии «конца света», когда очень глубокая реорганизация должна бы отменить уже финализированную транзакцию, сеть остановится, и пользователи будут вынуждены вручную разрешать конфликт так, как они сочтут нужным.
Однако глубина финальности должна быть достаточно большой, иначе краткосрочные атаки 51% могут привести к остановке сети. В Каспе ($KAS), например, значение этой величины установлено в 24 часа. Глубина варьируется от системы к системе (к примеру, потому, что системы с меньшей пропускной способностью могут позволить себе иметь более длинные окна финальности без чрезмерного роста требований к аппаратуре, на которой запускается нода сети), но порядок ее величины — всегда дни. Системы на PoW не в состоянии безопасно обеспечить быструю финальность, не создавая при этом чрезвычайно уязвимых мест.
Следующий лучший вариант — подтверждения типа консенсуса Накамото (NC). Теоретически NC гарантирует, что вероятность, что злоумышленнику с 49% мощности сети удастся отменить транзакцию, уменьшается экспоненциально от времени. Эта форма гарантии слабее, поскольку:
Она не обеспечивает защиты от атакующих с 51% мощности;
Даже если атакующего с 51% не существует, гарантия является «только лишь» вероятностной.
Поскольку у нас нет способа точно измерить время в рамках консенсуса (метками времени в блоках можно манипулировать), то единственный доступный способ, которым мы можем приближенно оценить периоды времени — подсчет числа блоков.
Таким образом, безопасность NC утверждает, что вероятность успеха 49%-ного злоумышленника экспоненциально уменьшается в зависимости от количества блоков, уложенных поверх блока с целевой транзакцией. И здесь есть одна очень важная тонкость: это свойство имеет место только в том случае, если доля блоков-«сирот» в сети очень мала. Именно в этом причина, по которой традиционные блокчейны не масштабируются: увеличение скорости или размера блоков приведет к увеличению количества блоков-«сирот» и ухудшению безопасности. Причина, по которой мы говорим, что Каспа решает криптовалютную трилемму, заключается в том, что протоколу GHOSTDAG удается устранить это препятствие: поскольку блоки в нем не становятся «сиротами», рост скорости генерации блоков не ухудшает безопасности сети. Чтобы узнать больше о том, как это работает, смотрите мой старый пост на Medium.
Поэтому, когда мы говорим, что у Каспы есть «мгновенные подтверждения», мы имеем в виду, что это единственная технология на PoW, которая обеспечивает подтверждения типа консенсуса Накамото настолько быстро, насколько позволяет сеть. Во всех других технологиях PoW скорость создания блоков должна быть достаточно низкой, чтобы избежать появления блоков-«сирот». Например, сеть Кадена разделена на несколько традиционных чейнов (шардов), поэтому хотя она может, в теории, генерировать до 20 блоков в секунду, но каждый отдельный чейн имеет 30-секундное время генерации блока, которое нельзя уменьшить без ущерба для безопасности. И хотя ChainWeb позволяет «склеивать» множество чейнов так, что атакующий должен атаковать их все вместе, пользователю все равно приходится ждать подтверждения в какой-то конкретной цепочке, содержащей его транзакцию. Вот почему, несмотря на высокую общую скорость генерации блоков, время подтверждения там остается долгим, и с решением трилеммы ChainWeb не справляется.
Другой интересный пример — Хатор. Грубо говоря, сети Hathor формируют DAG (направленный ациклический граф) транзакций, аналогичный Tangle 1.0 Йоты. Однако, чтобы избежать проблем с живучестью, они также создают и традиционный чейн, блок которого может указывать на транзакцию из DAG (а вознаграждение за блок стимулирует майнеров искать блоки для этого чейна). Чтобы счесть тут транзакцию безопасной в смысле NC, на нее должен ссылаться блок, достаточно глубоко расположенный в чейне. Таким образом, архитектура Хатор также не может обеспечить быструю безопасность типа консенсуса Накамото.
Учитывая все сказанное, становится ясно, что, например, биткойновское «правило шести блоков» является не столько правилом, сколько рекомендацией. Всегда ли оно применимо? Я бы сказал, нет. Например, если кто-то переведет мне безумное количество биткойнов, достаточно ценное, чтобы ради них профинансировать атаку 51% длиной в 20 блоков, я стану ждать дольше. На самом деле, для безумно больших сумм я бы вообще не рассчитывал на консенсус Накамото, а скорее подождал бы несколько дней, пока в силу вступит правило финальности (и вообще всё это, конечно, чрезвычайно упрощенно. Во-первых, для атаки 51% требуется гораздо больше, чем деньги: например, дефицитное специализированное оборудование. Кроме того, успешная двойная трата биткойнов на глубине 20 блоков обесценит, вероятно, вообще весь крипторынок до такой степени, что атака в итоге окажется очень невыгодной. Но вы меня поняли).
Общая особенность, которую я вижу во многих технологиях, заключается в том, что пользовательский интерфейс соответствующего кошелька или эксплорера реестра помечает транзакцию как «подтвержденную» в ту же секунду, когда она появляется в блокчейне. Такой интерфейс очень сильно вводит в заблуждение. «Гарантии» в данном случае бессодержательны. Я подозреваю, что некоторые проекты прибегают к такому трюку потому, что так их технологии кажутся более быстрыми, чем они есть на самом деле, но это очень безрассудное поведение, поскольку оно создает у пользователей ложное впечатление, что транзакция «подтверждена», слишком рано, когда фактически она еще неустойчива. Так что это лишь вопрос времени, когда кто-то продаст что-то ценное, разойдется с покупателем, поскольку транзакция «подтверждена», а затем обнаружит, что блок был потерян, задним числом (вероятностью чего нельзя пренебречь, если транзакция расположена в новейшем блоке). Мне хочется, чтобы вы это осознали: плохие решения пользовательского интерфейса, разработанные для того, чтобы технология казалась быстрее, чем есть, ведут к сценариям, когда пользователь теряет деньги, даже если обе стороны сделки были честными. По этой причине кошельки Каспы отображают транзакции как «подтвержденные» только после того, как глубина блоков, в которых они проведены, составит не менее десяти секунд.
Теперь мы подошли к самой слабой форме подтверждения, которую я называю «рациональным подтверждением». В этом типе подтверждения вам не дается никакой гарантии, что атака невозможна или требует больших ресурсов и/или удачи. Но зато гарантируется, что атака «нерациональна»: хотя противник может очень легко провести атаку, она причинит ему больше вреда, чем вам.
Преимущество рационального подхода заключается в том, что он не зависит от консенсуса Накамото и, таким образом, может быть очень быстрым. Недостаток — то, что на него гораздо больше влияют внешние факторы (например, стимулы для стороны А причинить вред стороне Б даже за счет причинения вреда себе), и эти внешние факторы намного сложнее предсказать и проанализировать.
В качестве примера рассмотрим очень хорошую идею: доказательства двойной траты (DS) криптовалюты Некса.
Прежде чем я продолжу, и чтобы заранее снять ненужное напряжение, еще раз подчеркну, что в мои намерения не входит доказывать, что доказательства DS плохи. Это не так. Они классные. Это аккуратная, простая для понимания идея, которая наглядно демонстрирует обе стороны компромисса в рациональных подтверждениях, и она приведена здесь только в качестве хорошего примера. Все, о чем я рассуждаю, применимо к любым формам рациональных сдерживающих факторов (скажем, социальному слэшингу в системах PoS) как к форме безопасности. Я, кроме того, ограничиваю обсуждение только одной из двух форм DS-доказательств, разработанных Некса, а именно — «DS-обнаружение» («DS detect»).
Идея доказательств DS проста: когда Алиса платит Бобу, скажем, одну Nexa за чашку кофе, она делает это с помощью транзакции особого вида. В этой транзакции Алиса блокирует, скажем, 5 Nexa на депозите. Если Алиса попытается потратить ту же самую Nexa, чтобы купить чашку кофе у Чарли, какой-нибудь майнер заметит двойную трату. Затем майнер может опубликовать подтверждение этой двойной траты, чтобы истребовать себе депозит Алисы. Боб, зная об этом протоколе, получает следующую гарантию: как только транзакция Алисы попадает в мемпул, даже до того, как она окажется в блоке, он знает, что если Алиса попытается провести двойную трату, она потеряет 5 Nexa. Так что, да, Алиса может использовать одну и ту же Nexa, чтобы купить чашку кофе и у Боба, и у Чарли, и, да, платеж пойдет только одному из них, но, как следствие, Алиса окажется оштрафована на 5 Nexa.
Это дает интересный компромисс. С одной стороны, гарантия не является функцией времени, а применяется моментально (и это и есть тип подтверждения, о котором идет речь, когда утверждается, что «Некса предлагает подтверждения с нулевым временем ожидания»). С другой стороны, она значительно слабее, чем гарантия по консенсусу Накамото. Она не предотвращает нападение, а «лишь» удерживает от него. Кроме того, стоимость депозита может не отражать рационального аспекта проблемы: возможно, имеются внешние факторы, которые делают для Алисы выгодным заплатить 50 000 Nexa, чтобы причинить Бобу ущерб в размере 10 000 Nexa. Например, Алиса может быть злым бизнес-магнатом, который хочет выкинуть Боба из бизнеса, чтобы затем снести его хибарку и построить там торговый центр или небоскреб. Другой пример: Алиса может быть майнером с 10% хешрейта сети, тогда она может заплатить Бобу 1 Nexa за его кофе, а при этом майнить блок, в котором она разместила а) конфликтующую транзакцию, в которой платит 1 Nexa себе, а также б) доказательство собственной двойной траты. Если Алисе удастся добыть следующий блок, она получит чашку кофе бесплатно. Если ей не удастся найти блок, то она заплатит за чашку выпитого кофе, но ее нападение останется скрытым, и ее не оштрафуют за попытку. Иными словами, 10%-й майнер атакует доказательства DS, что дает ему 10%-й шанс на двойную трату, но не подвергает какому-либо риску. Единственный способ избежать такой атаки — это подождать и увидеть транзакцию в блокчейне, то есть вернуться к использованию консенсуса Накамото, вместе с характерным для него временем подтверждения.
В заключение обсуждения DS-доказательств, если бы мне пришлось выразить всё одним предложением, я бы сказал, что они позволяют продавцам получать немедленные подтверждения, но требуют, чтобы они запрашивали депозиты. Очень большой депозит (порядка стоимости атаки 51%) делает их бизнес невыгодным, а гарантия безопасности ослабевает по мере уменьшения депозита.
С более общей точки зрения рациональные протоколы подтверждения, типа DS-обнаружения, позволяют получателям идти на риск ради улучшения собственной «отзывчивости». Это неплохо, всегда приятно иметь варианты.
Итак, резюмируя, есть три типа подтверждений: детерминированные, NC и рациональные. Каждое из них дает гарантии более слабые, чем предыдущее, но взамен может дать другие преимущества. Например, консенсус Накамото может быть децентрализованным, при том, что в настоящее время нет децентрализованных технологий, которые предлагают быструю объективную финальность, а рациональные подтверждения могут быть мгновенными, тогда как консенсус Накамото требует ожидания включения транзакции в блок, и погребения этого блока под несколькими следующими.
Когда вы видите, что кто-то говорит о «времени подтверждения», нужно всегда быть осторожным в отношении того, какой тип подтверждения в этот момент обсуждается, и я надеюсь, что идеи, высказанные в этой статье, помогут вам стать критичнее в дискуссиях.