Главными из них являются ограничения, влияющие на пропускную способность системы.
Сколько транзакций может выполнять сетевой процесс Bitcoin в секунду?
Это ограничение исходит из жесткого кодированного ограничения на размер блоков.
Каждый блок ограничен мегабайтом, около миллиона байт.
Каждая транзакция составляет не менее 250 байт.
Разделив 1,000,000 на 250, мы видим, что каждый блок имеет ограничение в 4000 транзакций, и, учитывая, что блоки добываются примерно каждые 10 минут, у нас получается около 7 транзакций в секунду, что все, что может обслуживать сеть Bitcoin.
Может показаться, что изменение этих ограничений было бы вопросом настройки константы в исходном файле кода где-нибудь.
Однако на практике это очень сложно осуществить по причинам, которые мы рассмотрим.
Итак, с чем сравнить семь транзакций в секунду?
Это довольно медленно по сравнению с пропускной способностью любого крупного оператора кредитных карт.
Например, сеть Visa обслуживает в среднем около 2000 транзакций в секунду по всему миру и способна обрабатывать 10 000 транзакций в секунду в пиковые периоды.
Даже Paypal, который меньше, чем Visa, может обрабатывать 100 транзакций в секунду в пиковые периоды.
Это на порядок больше, чем биткойн.
Еще одно ограничение, которое обсуждают, заключается в том, что набор криптографических алгоритмов в биткойне фиксирован.
Доступно только несколько алгоритмов хэширования и только один алгоритм подписи (ECDSA, по определенной эллиптической кривой, называемой secp256k1).
Существует некоторая озабоченность тем, что в течение жизни Биткойна, которая, как надеются люди, будет очень долгой – этот алгоритм может быть взломан.
Криптографы могут придумать умную новую атаку, которую мы не предвидели, что сделает алгоритм небезопасным.
То же самое относится к хэш-функциям; на самом деле, в последние десятилетия хеш-функции усиленно изучались.
Хэш функция SHA-1, которая используется в биткойне, уже имеет некоторые известные криптографические недостатки, хотя и не фатальные.
Чтобы обойти это ограничение, требуется расширить язык скриптов биткойнов для поддержки новых криптографических алгоритмов.
Как мы можем внедрять новые функции в протокол Bitcoin?
Вам может показаться, что это просто – просто выпустить новую версию программного обеспечения и сообщить всем узлам об обновлении.
В действительности, однако, это довольно сложно.
На практике невозможно быть уверенным, что каждый узел обновится.
Некоторые узлы в сети могут не получить новое программное обеспечение или могут не получить его вовремя.
Последствия обновления большинства узлов, в то время как некоторые узлы будут использовать старую версию, во многом зависят от характера изменений в программном обеспечении.
Мы можем различать два типа изменений: те, которые вызовут жесткий форк, и те, которые вызовут мягкий форк.
Жесткий форк, это когда вводятся новые функции, которые раньше считались бы недействительными.
То есть новая версия программного обеспечения распознает блоки как действительные, однако старое программное обеспечение эти блоки отбросит.
Теперь рассмотрим, что произойдет, когда большинство узлов обновятся, а некоторые узлы не обновятся.
Очень скоро самая длинная ветвь будет содержать блоки, которые не обновленные узлы считают недействительными.
Поэтому не обновленные узлы будут отбрасывать эту ветвь и будут работать с веткой цепочки блоков, которая не содержит блоки с новой функцией.
Пока они не обновят свое программное обеспечение, они будут считать, что их, более короткая ветка является самой длинной валидной веткой блокчейна.
Этот тип изменений называется жестким форком, поскольку он жестко разделяет цепочку блоков.
Каждый узел в сети будет находиться на той или иной стороне, в зависимости от того, какая версия протокола на нем запущена.
Конечно, при этом ветки никогда не смогут объединиться снова.
Это считается неприемлемым для сообщества, поэтому старые узлы будут эффективно отключены от сети Bitcoin, если они не обновят свое программное обеспечение.
Второй тип изменений или мягкий форк, которые мы можем внести в биткойн, – это добавление функций, которые делают правила проверки более строгими.
То есть они ограничивают набор допустимых транзакций или набор допустимых блоков, так что старая версия будет принимать все блоки, тогда как новая версия будет отбрасывать некоторые блоки.
Этот тип изменений называется мягким форком, и здесь можно избежать постоянного раскола, который создает жесткий форк.
Подумайте, что произойдет, когда мы представим новую версию программного обеспечения с мягким форком.
Узлы, на которых запущено новое программное обеспечение, будут применять новый, более жесткий набор правил.
При условии, что большинство узлов переключится на новое программное обеспечение, эти узлы обеспечат применение новых правил.
Существует риск того, что не обновленные майнеры могут использовать недействительные блоки, поскольку они будут включать некоторые транзакции, которые недействительны в соответствии с новыми, более строгими правилами.
Но не обновленные узлы, по крайней мере, поймут, что некоторые из их блоков отклоняются, даже если они не понимают причину этого.
Это может побудить их обновить программное обеспечение.
Кроме того, если их ветку обгонят обновленные майнеры, не обновленные майнеры переключаются на новую ветку, потому, что блоки, считающиеся действительными для новых майнеров, также считаются действительными старыми майнерами.
Таким образом, здесь не будет жесткой развилки; вместо этого будет много маленьких временных вилок.
И в конце концов все они объединятся в длинную ветку, при условии, что большинство улов обновится, так как все эти маленькие ветки будут обгоняться длинной веткой обновленных узлов.
Классическим примером изменения, которое было сделано с помощью мягкого форка, является введение функции pay-to-script-hash, о котором мы говорили ранее.
В первой версии протокола биткойнов нет pay-to-script-hash.
Это мягкая вилка, потому что с точки зрения старых узлов действительная транзакция с оплатой за скрипт будет проверяться корректно.
С точки зрения старых узлов, скрипт прост – он хэширует одно значение данных и проверяет, соответствует ли этот хэш значению, указанном в выходном скрипте.
Старые узлы не знают, как выполнить дополнительный шаг для запуска этого значения или скрипта, чтобы увидеть, является ли он допустимым скриптом.
Мы полагаемся на новые узлы для обеспечения соблюдения новых правил, то есть скрипт должен потратить эту транзакцию.
Что мы можем добавить с помощью мягкой вилки?
Кроме Pay-to-script-hash.
Также возможно, что новые криптографические схемы могут быть добавлены мягким форком.
Мы могли бы также добавить некоторые дополнительные метаданные в параметр coinbase, которые бы что-то значили.
Сегодня любое значение принимается в параметре coinbase.
Но мы могли бы в будущем сказать, что coinbase должнен иметь определенный формат.
Одна идея, которая была предложена, состоит в том, что в каждом новом блоке coinbase будет указывать корень Merkle дерева, содержащего весь набор не потраченных транзакций.
Это приведет только к мягкой вилке, потому что старые узлы могут иметь блок, у которого нет требуемого нового параметра coinbase и который был отклонен сетью, но они наверстают упущенное и присоединятся к основной цепочке, которую ведет сеть.
Для других изменений может потребоваться жесткая вилка.
Примером этого является добавление новых опккодов в биткойн, изменение ограничений на размер блоков или транзакций, или различные исправления ошибок.
