Масштабируема ли Каспа?
От участников сообществ альтернативных криптопроектов звучат голоса: «Каспа не масштабируема», «у нее маленький размер блока».
Так масштабируема ли Каспа?
tl;dr:
1. Да.
2. Лучше, чем любой другой PoW проект.
И чуть подробнее — ниже.
Прежде всего, о масштабировании при сохранении каких характеристик системы идет речь?
Я полагаю, раз мы говорим о PoW проекте, то нас интересует прежде всего масштабируемость в рамках ограничений, накладываемых парадигмой консенсуса Накамото. PoS проекты — отдельная область со своими правилами. Выход же проекта на технологиях PoW за пределы системы консенсуса Накамото тоже переносит нас в иную область, с пониженными гарантиями надежности (но это, к слову сказать, не значит, что Каспа не способна показать себя и там — этому я уделю внимание в последней части статьи). Чтобы разделить две последние области, а заодно лучше понять, что такое «время подтверждения», потому что оно будет играть важную роль в дальнейшем повествовании, следует прочитать великолепную статью Шаи «Деше» Выборски о временах подтверждения.
Так что такое вообще масштабирование? Судя по всему, под этим обычно понимают повышение пропускной способности сети по передаче транзакций, необходимость в котором будет расти по мере роста популярности сети и согласно с ростом аппаратных возможностей сетей связи и аппаратуры обработки данных. Соответственно, ограничение на масштабируемость может обуславливаться двумя факторами: внутренними имманентными ограничениями логической организации системы, и возможностями системы по адаптации к улучшению параметров аппаратуры передачи и обработки данных. Рассмотрим оба аспекта.
Начнём с логической части. Каспа в логической ее части дает масштабируемость лучше, чем любой другой проект на PoW. Почему? Объясняю.
Традиционные блокчейны вообще не масштабируются, если задача стоит «масштабироваться при сохранении того же уровня безопасности», то есть мы не можем ускорить передачу транзакций в блокчейне, придерживаясь консенсуса Накамото, и не пожертвовав безопасностью. Это вроде как общеизвестно, но я еще раз поясню, в чем дело. Устойчивость сети блокчейна к атакам базируется на предположении, что в каждый момент времени вся сеть работает на поиск очередного блока, и атакующему нужно работать быстрее всей сети, чтобы смочь переписать ее историю, отменив таким образом интересующие его транзакции и вставив вместо них свои. И сеть, действительно, большую часть времени работает так — кроме тех моментов, когда в ней возникают параллельные цепочки. Параллельные цепочки возникают потому, что всегда есть шанс, что, пока информация об одном блоке (блоке А) распространяется по сети, кем-то еще будет найден другой блок (блок Б). А время распространения информации по сети зависит не только от скорости сетевых интерфейсов, но и от скорости валидации блоков нодами: нода, пока не убедится, что блок валиден (или хотя бы валиден его заголовок), не имеет права передавать информацию о нем своим соседям. Поэтому информация о блоке А расходится с некоторой задержкой. Если в это время в другой части сети кем-то обнаруживается блок Б, информация о нем распространяется по близлежащим нодам быстрее, чем до них доходит информация о блоке А, и они майнят с того момента поверх блока Б. И даже когда узнают о блоке А, майнить будут все равно поверх Б: так работает классический блокчейн. Дело в том, что ноды не имеют возможности решить, какой из двух таких блоков-кандидатов имеет преимущество: доверия штампам времени в заголовках блоков нету — их можно подделать, поэтому для любой ноды тот блок, о котором она узнала первым, и есть «более правильный». Дальше ситуация сосуществования параллельных блоков сохранится до тех пор, пока над одним из блоков, А или Б, не будет найден очередной: тогда его цепочка становится длиннее, и она уже выигрывает соревнование по этому критерию.
В чем здесь подвох: все время, пока в сети существуют два параллельных блока, майнинговая мощность сети разделена. И злоумышленнику нужно атаковать не всю сеть, а лишь ту часть сети, что работает над блоком, который победит. Поэтому вероятность появления двух блоков одновременно нужно по возможности минимизировать — иначе, чем чаще в сети станут появляться два блока одновременно, тем чаще она будет иметь пониженную способность к самозащите. Именно поэтому Сатоши установил время блока аж в 10 минут: возможность возникновения распараллеливания случается в среднем именно так редко, и ненадолго, пока инфа о блоке не распространится (при этом длительность сохранения параллельности никак от этого не зависит, увы и ах). Проекты-потомки и форки еще снизили это время, но это гарантированно привело к их пониженной, по сравнению с Битком, надежности. Я скажу даже больше: одновременно может существовать не только два параллельных блока, но и три, и четыре — теория вероятности это не запрещает, просто шанс такого события мал. Соответственно, защищенность сети становится не вдвое, а втрое, вчетверо ниже на это время. Подумайте о форках Биткойна, где шанс двойной/тройной/четверной генерации возникает не раз в 600 секунд на несколько секунд, а раз в 30. Неплохо, не правда ли.
А теперь представьте, что будет, если установить в блокчейне время появления блока меньше времени распространения блока по сети? Для блокчейна это моментальная фатальная катастрофа. Параллельные блоки сию же секунду начнут размножаться быстрее, чем сеть будет о них узнавать, и результатом станет полный развал системы. Каждый будет майнить поверх того, что бог послал узнать на данную секунду, и этот кисель расползется в бесконечность; ни о каком распределенном согласии нод относительно состояния сети говорить не придется уже никогда.
Та же Кадена нашла решение в сосуществовании нескольких параллельных цепочек, перекрестно связанных математически красивым фиксированным образом: это дало им возможность в целом по сети генерировать блоки с паузами между ними меньшими, чем время распространения блока по сети. Но у них осталась другая нерешаемая при таком подходе проблема: время подтверждения. Чтобы убедиться, что транзакция надежно прошла, пользователю придется ждать, пока она будет подтверждена заметным количеством блоков именно в той цепочке из графа цепочек системы, в которой он эту транзакцию разместил. Заметьте, что каждая цепочка в Кадене подвержена абсолютно той же вероятности ее неожиданного распараллеливания, что и обычный блокчейн — потому что каждая цепочка и есть обычный блокчейн. Поэтому уменьшить время ожидания там никак нельзя: а вдруг транзакция попала в параллельную подцепочку и будет скоро отменена, после проигрыша подцепочки в соревновании? Поэтому для Кадены время ожидания подтверждения транзакции равно в среднем N*30 секунд, где N — число блоков поверх блока с пользовательской транзакцией, которое тот считает надежным, а 30 секунд— среднее время появления блока в каждой из цепочек Кадены.
Так вот, в свете всего сказанного, Каспа — единственный проект, который может позволить себе роскошь установить время генерации блока в сети меньше, чем время распространения информации о нем, при этом одновременно а) не жертвуя защищенностью, и б) обеспечивая время подтверждения по Накамото порядка времени распространения блока по сети! Единственный. То есть по мере роста скорости передачи данных в сетях связи и роста вычислительной способности аппаратуры другие проекты смогут, видимо, позволить себе сократить время между блоками — но при этом вынуждены будут продолжить подчиняться условию «время между блоками значительно больше времени распространения блока». То есть, положим, если для Кадены время распространения было 5 секунд, а стало 2, то они смогут позволить себе генерировать блок не раз в 30 секунд, а раз в 12 с сохранением прежнего уровня защищенности. Но приблизиться к 2 секундам им все так же не удастся: уменьшить время блока еще сильнее означает потерять в защищенности. Каспа же может напрямую перестроить свою логику под новое ожидаемое время распространения блоков, ускорив время подтверждения и улучшив пользовательский опыт. А скорость генерации блоков у нее и так отвязана от времени распространения, поэтому может напрямую расти с ростом пропускной способности сети, даже если при этом задержки типа пингов в сети остаются прежними.
Следующий пункт: «у Каспы маленькие блоки». Это вообще аргумент, лишенный смысла. Во-первых, в Каспе размер блока — не догма, а некое довольно произвольно выбранное значение, и всегда можно его поменять. Вот блокчейн не может позволить себе произвольно менять размер блока — это напрямую влияет на время распространения блока по сети: чем больше блок, тем дольше длится его передача и его валидация. Соответственно, понижается защищенность сети (растет шанс создать параллельный блок). Именно поэтому в Биткойне долгое время сопротивлялись увеличению размера блока и дело по этой причине даже дошло до хардфорка, после чего появился очередной из многих форков Битка (конкретно — Bitcoin Cash), а в основной ветке развития был использован другой механизм увеличения пропускной способности, так называемый SegWit. Во-вторых, Каспе и нет особой необходимости повышать размер блока: она может вместо этого повысить при необходимости частоту их генерации. Это даст ожидаемое увеличение пропускной способности, и при этом дополнительным преимуществом станет то, что пользователю придется в среднем меньше времени ждать перехода транзакции из мемпула в блок, то есть это дополнительно улучшит пользовательский опыт. Поэтому размер блока не имеет в Каспе никакого критического значения и не является ограничением с практической точки зрения.
Можно задуматься еще об эффективности использования полосы пропускания. В принципе, Каспа в первом приближении не менее эффективна, чем блокчейны, потому что в блоке Каспы заголовок занимает довольно небольшое пространство, порядка килобайт, а размер самого блока равен 500 000 байт, то есть на «служебные данные» приходится меньше 1% пропускной способности сети, всё остальное отдано под описание транзакций в виде, характерном для всех койнов, где расчет баланса основан на модели UTXO. То есть о низкой эффективности использования канала связи говорить тоже не приходится. Более того, всегда необходимо искать компромисс между тем, насколько быстро будет работать сеть проекта в целом, и насколько децентрализованной она при этом будет, потому что в сети наверняка присутствуют аппаратно слабые ноды, которые не способны окажутся обрабатывать поток данных сети выше какого-то определенного порога — при скорости блоков или потока транзакций, превышающих некий предел. Но это, опять же, не проблема Каспы как таковой: с одной стороны — это проблема аппаратуры, а с другой стороны — эта проблема точно так же стоит и перед абсолютно всеми остальными блокчейнами в идентичном виде. Для любого блокчейна не исключено, что типичная нода будет слишком слабой, чтобы успевать обрабатывать все блоки и транзакции сети. Или, если в блокчейне используются какие-то механизмы обхода ограничений, связанных с блоками — например, передаются только транзакции, как это сделано а Hathor — то ведь эти транзакции нужно тоже как-то передать, где-то сохранить и обработать, то есть все равно работа системы будет упираться в пропускную способность канала связи и мощность аппаратуры ноды. Далеко не каждый компьютер способен будет в реальном времени поддерживать потребную скорость обработки в сотни тысяч транзакций в секунду. Каспа здесь не в худшем и не в лучшем положении, чем все остальные блокчейны, и по этому параметру не проигрывает никак.
То есть, в общем и целом, масштабируемость Каспы в рамках сохранения консенсуса Накамото не то что не хуже, а лучше, чем у остальных PoW проектов.
Теперь, многие проекты базируют часть своей функциональности на технологиях, отличающихся от консенсуса Накамото, и заявляют на этом основании, что они имеют масштабируемость повышенную по сравнению с тем, что предлагают более традиционные проекты. Как то, например, DAG транзакций в Hathor-е, существующий и передаваемый отдельно от его блокчейна. Или как транзакции с нулевым временем подтверждения, как в Нексе, где продавец может узнать о транзакции, когда она еще в мемпуле. Это и неплохо, пожалуйста, вариативность всегда хороша. Но, даже оставив в стороне вопрос о надежности решений, предлагаемых нетрадиционными, не-Накамотовскими схемами, по сравнению со схемой Накамото, все равно следует сказать, что на этом основании нельзя утверждать, что Каспа менее масштабируема. Потому что Каспа, как продукт, основанный в значительной мере на концепциях и технологиях Биткойна, имеет все необходимые элементы инфраструктуры для того, чтобы реализовать большую часть тех трюков, что были придуманы с целью обойти накладываемые традиционными блокчейнами ограничения, связанные с тем, что в блокчейне частота блоков по необходимости довольно мала.
Тот же мемпул в Каспе, скажем, тоже есть, и ноды обмениваются между собой содержимым мемпула параллельно с процессом обмена информацией о блоках. И если кому-то интересно будет видеть транзакцию в мемпуле и пользоваться ее «итогами», пока она еще в мемпуле и не включена в блок — Каспа этому никак не препятствует в теории, всегда можно реализовать такую возможность. А дальше возникает вопрос. Вот транзакция с нулевым временем подтверждения в Нексе: продавец увидел транзакцию в мемпуле, и он может сразу на нее рассчитывать. Но кто сказал, что транзакция попадет в блок за время, устраивающее продавца, или что она, в предельном случае, вообще попадет в блок? Ведь всегда есть шанс, что в пуле будут находиться более высокоприоритетные транзакции, и эта транзакция с нулевым подтверждением либо будет висеть в нем очень долго, ожидая включения в блок, либо вообще провисит в нем столько, что в итоге вылетит оттуда по таймауту. То есть продавцу, чтобы быть более-менее уверенным в том, что транзакция пройдет, надо бы дождаться попадания ее хотя бы в один блок — и что мы получаем? Хоть она и c нулевым подтверждением, но разумный продавец дождется, пока транзакция окажется в блоке, а среднее время появления блока, если не ошибаюсь, составляет в Нексе 2,5 минуты: ждите. То есть и при реализации у себя этой техники Каспа выиграет: у нее-то блоки идут гораздо чаще, чем у Нексы, и транзакция окажется в блоке, с точки зрения продавца, практически моментально, и он может, пожалуйста, воспользоваться своим правом принять 0-conf транзакцию и отпустить покупателя мгновенно, посчитав сделку состоявшейся. То есть даже при адаптации чужих техник Каспа в общем случае окажется более удобной для пользователя, чем остальные проекты.
Поэтому о том, что Каспа не масштабируема, может говорить только человек, знакомый с ней чрезвычайно поверхностно, если не вообще лишь только слышавший краем уха.
