Перейти к содержанию
Financial Context Wiki

Блокчейн: состояние, консенсус и проверка

Блокчейн — это версионный протокол для упорядочивания и проверки переходов состояний между репликами. Хэш-ссылки — это только один компонент; доверие зависит от консенсуса, разрешений, независимой проверки, доступности данных, управления и восстановления.

Обновлено

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

Краткий ответ

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

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

Блокчейны могут использовать модели состояния UTXO, учетной записи, объекта или приложения; доказательство работы, доказательство доли, византийское отказоустойчивое голосование или разрешенный консенсус; и вероятностная окончательность или окончательность на основе контрольных точек. Таким образом, слово «блокчейн» обозначает широкое семейство архитектур, а не одну гарантию безопасности или один продукт базы данных.

1
Создавать

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

Как это работает

  1. Точно укажите цепочку, сеть, версию протокола, модель разрешений, модель состояния и проверяемое утверждение. Зафиксируйте генезис или доверенную контрольную точку, идентификатор цепочки, реализацию клиента и полномочия на обновление.
  2. Сформируйте точные байты транзакции и авторизации. Перед распространением проверьте владельца адреса или входа, nonce либо ссылки на неизрасходованные выходы, сумму, адрес назначения, пределы комиссии, окно действия, подписи и вызовы приложения.
  3. Распространите транзакцию через узлы или шлюзы. Отличать локальную политику приема и мемпула от консенсусной действительности; узел может отклонить, задержать, заменить или никогда не получить транзакцию, которая могла бы быть действительной в блоке.
  4. Предлагающий выбирает и упорядочивает транзакции в блоке-кандидате и фиксирует такие поля протокола, как родительский блок и корни транзакций, квитанций, состояния или данных. Порядок может повлиять на результаты исполнения, комиссии, ликвидации и извлекаемую стоимость.
  5. Независимые узлы десериализуют блок, проверяют консенсусную авторизацию и каждый необходимый переход состояния, пересчитывают обязательства и отклоняют недействительные или недоступные входные данные в соответствии со своими правилами. Подписи производителей или доказательства работы не отменяют неудачную проверку.
  6. При выборе форка происходит выбор между конкурирующими действительными историями, а подтверждения, голосования или контрольные точки со временем меняют риск реорганизации. «Включено», «безопасно» и «завершено» — это разные состояния и зависят от протокола.
  7. Сверьте состояние протокола с намерением приложения, хранением активов, учетом моста или площадки и требованиями к архивированию. Сохраняйте байты транзакции, хэш блока, высоту или слот, квитанцию, журналы, доказательство состояния, статус окончательности, версию клиента и свидетельства от независимой конечной точки.

Рабочие примеры

  • Сверка состояния учетной записи. Исходный баланс учетной записи равен 10 ETH, а nonce — 41. Действительная транзакция с nonce 41 переводит 2 ETH и расходует 0.00042 ETH на комиссию, поэтому упрощенное последующее состояние равно 10 - 2 - 0.00042 = 7.99958 ETH, получатель получает 2 ETH, а nonce отправителя становится 42. Сама по себе действительная подпись не доказывает достаточность предыдущего баланса или успешное исполнение.
  • Сохранение UTXO. На транзакцию тратятся входы 0.80 BTC и 0.35 BTC на общую сумму 1.15 BTC. Выходы 1.00 BTC и 0.1496 BTC в сумме 1.1496 BTC; разница в комиссиях составляет 1.15 - 1.1496 = 0.0004 BTC. Узлы также должны проверять, что каждый указанный выход существует, неизрасходован и удовлетворяет условиям расходования.
  • Размер подтверждения обязательств. В наглядном сбалансированном двоичном дереве Меркла с 8 leaves для пути включения требуется log2(8) = 3 sibling hashes. При использовании хешей 256-bit = 32-byte эти братья и сестры занимают 3 * 32 = 96 bytes перед индексами и кодировкой. Доказательство связывает лист с заявленным корнем; это не доказывает, что исходные данные правдивы или доступны в настоящее время.
  • Вес — не количество узлов. В примере протокола голосования, где правило окончательности требует веса >= 2/3, веса валидаторов равны 30%, 25%, 20%, 15%, 10%. Первые три дают 30 + 25 + 20 = 75% и превышают порог, а первые два дают 55% и не достигают его. Фактические пороги, правила учета корреляции, противоречивого голосования и восстановления следует брать из указанного протокола.

Риски

  • Использование неправильной цепочки, сети, форка, контрольной точки или идентификатора цепочки.
  • Отношение к торговой марке как к полной спецификации протокола или модели доверия.
  • Предполагая, что только хеш-связь предотвращает авторизованные или одобренные консенсусом перезаписи.
  • Путаница предложения блока производителя с независимой проверкой узла.
  • Принятие, трансляция, включение, успешное выполнение и завершенность мемпула рассматриваются как одно состояние.
  • Подписание байтов, доменов или мест назначения, отличных от того, что отображается в интерфейсе.
  • Повторное использование nonce, расходование устаревших UTXO или неверный расчет комиссий и сдачи.
  • Доверие к символам токенов, меткам, событиям или интерпретациям проводника вместо идентификаторов и состояния протокола.
  • Рассматривать подписанные входные данные оракула, моста или документа как доказательство того, что утверждения вне цепочки верны.
  • Игнорирование порядка транзакций, цензуры, опережения и концентрации предлагающих или застройщиков.
  • Подсчет узлов или валидаторов без разрешения общих операторов, весов и инфраструктуры.
  • Игнорирование клиентов, облака, географии, управления, концентрации ключей и цепочки поставок программного обеспечения.
  • Предполагая, что все модели консенсуса имеют одинаковые пороги ошибок или семантику окончательности.
  • Игнорирование разделов, отложенной окончательности, реорганизаций, двусмысленностей и процедур восстановления.
  • Принятие заголовков блоков или доказательств без необходимых предположений о доступности данных.
  • В зависимости от одного RPC, проводника, кошелька, индексатора или кастодиальной платформы в качестве источника истины.
  • Путаница владения протоколом или контроля с юридическим правом собственности, правом обращения за помощью или возможностью возмещения.
  • Недооценка роста состояния, потери архивов, стоимости синхронизации и аппаратных барьеров.
  • Игнорирование ключей обновления, аварийных пауз, социального восстановления и спорных форков.
  • Определение конфиденциальности, масштабируемости, инвестиционной ценности или безопасности приложений на основе метки блокчейна.

Распространённые заблуждения

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

Похожие темы

Источники

Навигация

Поиск по вики...