Вопросы на собеседовании: Блокчейн-разработчик

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

• Каждый участвующий узел может хранить и проверять собственную копию, не полагаясь на один сервер базы данных.
• Протокол консенсуса определяет, какие корректные обновления и какой их порядок принимает сеть при разногласиях между узлами.
• Репликация повышает отказоустойчивость, но требует дополнительных сетевых обменов и не превращает каждую распределённую базу данных в блокчейн.
• Блокчейн является одним из видов распределённого реестра, в котором обновления обычно объединяются в связанные хешами блоки.

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

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

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

• Даже изменение одного бита с подавляющей вероятностью создаёт другой криптографический хеш.
• Следующий блок продолжает ссылаться на исходный хеш, поэтому изменённая история сразу не проходит проверку.
• Атакующему пришлось бы пересобрать изменённый блок и всех его потомков, а затем преодолеть правила консенсуса сети.
• Хеши делают вмешательство обнаружимым, а консенсус и экономические затраты мешают сети принять альтернативную историю.

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

• Публичные сети, например Ethereum, используют permissionless-валидацию и экономические стимулы, поскольку валидаторы могут не знать и не доверять друг другу.
• Приватные сети, например Hyperledger Fabric, могут ограничивать круг тех, кто читает данные, отправляет транзакции или проверяет обновления.
• Разрешительное членство может повысить пропускную способность и приватность, но концентрирует контроль у участвующих организаций.

Модель счетов обновляет балансы и состояние, связанные с адресами, а модель UTXO расходует существующие выходы и создаёт новые.

• У счетов Ethereum есть такие поля, как баланс и nonce, которые транзакции изменяют в общем глобальном состоянии.
• В Bitcoin выход расходуется целиком, поэтому платёж обычно создаёт один выход получателю, а другой возвращает сдачу отправителю.
• UTXO легко проверять независимо и можно обрабатывать параллельно, если они не расходуют одни и те же выходы.
• Счета упрощают представление балансов и состояния смарт-контрактов, но транзакции могут конкурировать за одно состояние.

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

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

Узлы передают новые транзакции и блоки подключённым пирам, и так данные распространяются по сети по принципу gossip.

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

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

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

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

• Каждый следующий блок добавляет подтверждение и снижает вероятность реорганизации в сети proof-of-work.
• Финальность в proof-of-work вероятностная, поэтому приложения ждут больше подтверждений при более высокой сумме или риске.
• Во многих proof-of-stake сетях валидаторы голосованием финализируют контрольные точки, после чего откат требует серьёзного нарушения протокола и влечёт штрафы.

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

• Ссылка на родителя должна указывать на известный корректный блок, а поля заголовка должны отвечать правилам консенсуса сети.
• Узел проверяет подписи транзакций, nonce или потраченные выходы, балансы и другие условия протокола.
• Он выполняет корректные транзакции по порядку и пересчитывает записанные в заголовке корни транзакций, квитанций или состояния.

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

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

В proof of work майнеры ищут хеш блока ниже текущего целевого значения сети.

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

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

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

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

• Соло-валидатор Ethereum вносит 32 ETH и запускает ПО, которое выполняет назначенные обязанности консенсуса.
• Для каждого слота один выбранный пропозер собирает и рассылает блок-кандидат.
• Другие валидаторы публикуют аттестации с голосами за голову цепочки и связи между контрольными точками, а протокол суммирует вес их стейка.
• Пропуск обязанности лишает потенциальной награды, а подпись противоречивых сообщений может привести к слешингу.

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

• Временный форк может возникнуть, когда разные блоки публикуются почти одновременно и доходят до узлов в разном порядке.
• Узлы проверяют каждую ветку до применения правила выбора, поэтому некорректный блок не победит лишь за счет продолжения ветки.
• Цепочки proof of work обычно предпочитают корректную ветку с наибольшей накопленной работой, а цепочки proof of stake используют голоса валидаторов и собственные правила протокола.
• Блоки вне выбранной ветки становятся неканоническими, а их транзакции могут включить снова, если они остаются корректными.

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

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

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

• В proof of work каждый дополнительный блок добавляет работу поверх транзакции, поэтому заменить ее ветку становится все менее вероятно и все дороже.
• В proof of stake контрольная точка может стать финализированной после того, как за нее проголосует требуемая правилами протокола доля стейка.
• Для отката экономически финализированной контрольной точки валидаторам пришлось бы нарушить проверяемые правила и рисковать значительной частью стейка.

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

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

Слешинг уничтожает часть стейка валидатора, когда криптографические доказательства подтверждают запрещенное действие в консенсусе.

• В Ethereum к наказуемым действиям относятся предложение двух блоков для одного слота и противоречивые или окружающие голоса.
• Подписанные сообщения служат доказательством, которое другие узлы проверяют без доверия к тому, кто его передал.
• Слешинг отличается от небольшого штрафа за неактивность, который может применяться к отключенному, а не нечестному валидатору.
• Штрафы растут, когда одновременно слешат много валидаторов, что мешает операторам использовать одну общую конфигурацию с единым риском отказа.

Блокчейны защищаются от атак Сивиллы, связывая влияние в консенсусе с дефицитным ресурсом, а не с числом идентификаторов.

• Создать тысячи пар ключей почти бесплатно, поэтому одни подписи не доказывают, что ключи принадлежат независимым участникам.
• Proof of work взвешивает влияние по вложенным вычислениям, для которых нужны оборудование и энергия.
• Proof of stake взвешивает влияние по заблокированному стейку, поэтому разделение тех же средств между множеством валидаторов не создает дополнительной общей силы голоса.
• Permissioned-сети могут вместо этого ограничивать участие через проверенные организации, сертификаты или процесс контроля доступа.