Тимур Машнин - Введение в технологию Блокчейн

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

Вот почему, желательно, чтобы каждый узел выполнял эти проверки.

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

Это становится особенно интересным и важным, когда есть попытка двойной траты.

Предположим, что Алиса пытается заплатит один и тот же биткойн как Бобу, так и Чарли, и отправляет две транзакции примерно в одно и то же время.

Некоторые узлы сначала услышат о транзакции Алиса → Боб, а другие сначала услышат о транзакции Alice → Charlie.

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

Узел откажется от последней транзакции и не будет ретранслировать ее или добавлять ее в пул транзакций.

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

Это называется созданием условия гонки.

Хорошей новостью является то, что все будет в порядке.

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

Скажем, транзакция Алисы → Чарли попадает в блок.

Когда узлы с транзакцией Алиса → Боб услышат об этом блоке, они выведут эту транзакцию из своих пулов ожидающих транзакций, потому что это двойная трата.

Также, когда узлы с транзакцией Alice → Charlie услышат об этом блоке, они выведут и эту транзакцию из своих пулов, потому что она уже попала в цепочку блоков.

Так что больше не будет никакого разногласия, когда этот блок распространится в сеть.

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

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

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

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

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

До сих пор мы в основном обсуждали распространение транзакций.

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

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

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

Проверка блока является более сложной, чем проверка транзакций.

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

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

Это позволяет избежать образования вилок.

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

Это создаст вилку, но все будет в порядке, потому что протокол биткойна разработан таким образом, чтобы противостоять этому.

Теперь вопрос, какова латентность алгоритма наводнения или сплетен?

График на слайде показывает среднее время, за которое новые блоки распространяются в каждый узел сети.

Три линии показывают время покрытия блоком 25, 50 и 75 процентов сети.

Как вы можете видеть, время распространения пропорционально размеру блока.

Это связано с тем, что пропускная способность сети является узким местом.

Большие блоки занимают более 30 секунд для распространения на большинство узлов в сети.

Таким образом, это не очень эффективный протокол.

В Интернете 30 секунд довольно долгое время.

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

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

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

Теперь вопрос, какой размер сети биткойнов.

Трудно измерить, насколько велика сеть, так как она динамична, и не существует центрального узла.

Ряд исследователей дают разные оценки.

Некоторые говорят, что более миллиона IP-адресов действуют одновременно, как узлы биткойна.

С другой стороны, оценивают, что в сети находятся только от 5000 до 10000 узлов, которые постоянно подключены и полностью проверяют каждую транзакцию, которую они слышат.

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

Чем дольше узел находится в автономном режиме, тем ему дольше придется восстанавливать актуальность данных, когда он снова присоединиться к сети.

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

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

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