Tower BFT

Что такое Tower BFT?

Tower BFT — это оптимизированный для Proof of History механизм консенсусного голосования Solana с византийской отказоустойчивостью.

В криптоиндустрии Tower BFT лучше всего понимать как систему, которая помогает валидаторам Solana голосовать за корректный форк, наращивать подтверждённость блоков и со временем делать откат всё более затратным.

В официальной документации Anza по Tower BFT объясняется, что Solana генерирует источник времени посредством Proof of History и использует слоты в качестве единицы времени.

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

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

Tower BFT — не то же самое, что Proof of History.

Proof of History предоставляет криптографические часы и структуру упорядочивания, тогда как Tower BFT использует эту временную структуру для организации голосов валидаторов, лок-аутов, выбора форка и подтверждённости.

В официальном документе Solana Proof of History описывается как доказательство для проверки порядка и хода времени между событиями.

Tower BFT развивает эту идею, позволяя валидаторам голосовать с лок-аутами, измеряемыми в слотах.

В криптовалютном глоссарии Tower BFT следует понимать как исходный BFT-подобный уровень консенсуса Solana, использующий временную структуру Proof of History для сокращения издержек координации и поддержки быстрого подтверждения блоков.

Почему Tower BFT важен

Tower BFT важен, поскольку консенсус — это процесс, позволяющий блокчейну согласовать единую общую историю.

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

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

Tower BFT способствует этой цели, используя Proof of History как общий ориентир времени до достижения полного консенсуса.

В официальной статье Solana о Tower BFT Tower BFT описывается как специальная реализация PBFT, использующая Proof of History в качестве часов до консенсуса для сокращения затрат на обмен сообщениями и задержки.

Это важно для пользователей, поскольку консенсус влияет на подтверждение транзакций, ожидания финальности, поведение валидаторов и надёжность сети.

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

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

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

Таким образом, Tower BFT — не только деталь работы валидаторов, но и часть более широкой рыночной инфраструктуры криптовалютной активности на базе Solana.

Что означает BFT?

BFT означает Byzantine Fault Tolerance — византийская отказоустойчивость.

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

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

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

Безопасность означает, что честные участники не должны финализировать противоречивые истории.

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

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

Это не простое голосование большинством по числу валидаторов.

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

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

Tower BFT и Proof of History

Proof of History — временная основа, которая отличает Tower BFT от многих традиционных BFT-систем.

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

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

В документе Solana указано, что Proof of History может кодировать не требующее доверия течение времени в реестре с добавлением записей.

Это даёт Tower BFT возможность измерять лок-ауты голосов в слотах, а не полагаться только на локальные часы и повторные переговоры.

Проще говоря, Proof of History даёт сети общую временную шкалу, а Tower BFT использует её для организации консенсусных голосов.

Поэтому Tower BFT часто описывают как BFT, оптимизированный для PoH.

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

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

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

Tower BFT и слоты

Слот — единица времени Solana для производства блоков и голосования валидаторов.

В Tower BFT лок-ауты и обязательства по голосованию измеряются в слотах.

В документации Anza по Tower BFT указано, что у каждого слота есть назначенный лидер, который может произвести блок.

Лидер может не произвести блок, поэтому некоторые слоты могут не содержать блоков.

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

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

Блок связан со слотом, а голоса могут ссылаться на блоки в форке.

Это позволяет Tower BFT объединять время, ротацию лидеров, выбор форка и обязательства валидаторов в единый процесс.

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

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

Tower BFT и голоса валидаторов

Голоса валидаторов — ключевое действие в Tower BFT.

Голос сообщает, какой блок или форк поддерживает валидатор.

В документации Anza по Tower BFT голос описывается как подписанный валидатором и сформированный вокруг идентификатора валидатора и хеша блока, за который подаётся голос.

Голоса — не просто мнения.

Они создают лок-ауты, ограничивающие, за что валидатор сможет голосовать далее.

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

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

Tower BFT превращает голосование в обязательство.

Это обязательство становится сильнее по мере накопления голосов за один форк.

Название «Tower» происходит от этой структуры накопленных обязательств.

Что такое лок-аут в Tower BFT?

Лок-аут — это период времени, в течение которого валидатор ограничен в голосовании за противоречащий форк.

В документации Anza по Tower BFT указано, что лок-аут измеряется в слотах и не позволяет валидатору голосовать за другой форк в течение этого периода.

Цель лок-аута — создать для валидатора альтернативные издержки обязательства по форку, который он поддержал.

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

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

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

Лок-ауты также помогают клиентам оценивать стоимость отката.

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

Это один из основных способов, которыми Tower BFT превращает краткосрочные голоса в более высокую уверенность в расчётах.

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

Как накапливаются лок-ауты

Tower BFT использует стек недавних голосов и их лок-аутов.

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

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

Это создаёт башнеподобную структуру обязательств по голосованию.

Новый голос может иметь короткий лок-аут.

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

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

Она также даёт клиентам возможность оценить, насколько затратно было бы отменить блок.

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

Поэтому Tower BFT тесно связан с поведением подтверждённости и финальности Solana.

Tower BFT и выбор форка

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

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

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

Tower BFT помогает валидаторам оценивать эти форки и в итоге выбрать один из них.

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

Голоса с весом стейка помогают сети сходиться вокруг одного форка.

Лок-ауты удерживают валидаторов от частого переключения между противоречащими форками.

Со временем это делает выбор форка стабильнее.

Форк с более сильными голосами, взвешенными по стейку, и более глубокими лок-аутами сложнее заменить.

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

Tower BFT и корни

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

В документации Anza по управлению форками объясняется, что корень — это слот, достигший максимальной глубины лок-аута.

После установления корня валидатор может удалить форки, не происходящие от этого корня.

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

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

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

Корень не означает исчезновение каждого теоретического риска.

Это означает, что валидатор считает откат достаточно затратным или нереалистичным при обычных предположениях.

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

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

Tower BFT и финальность

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

Tower BFT поддерживает финальность посредством повторных голосов с весом стейка и увеличивающихся лок-аутов.

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

Это даёт пользователям и приложениям растущий уровень уверенности по мере появления новых слотов поверх транзакции.

Финальность — не только метка пользовательского интерфейса.

Это свойство консенсуса, связанное с голосами валидаторов, весом стейка, глубиной лок-аутов и выбором форка.

В системах типа Solana транзакция может отображаться как обработанная до достижения наиболее сильного уровня подтверждённости.

Приложениям следует выбирать уровни подтверждённости с учётом допустимого риска.

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

Tower BFT — механизм, лежащий в основе этого постепенного перехода от предварительного включения к более сильной подтверждённости.

Tower BFT и супержбольшинство

Поддержка супержбольшинства важна для BFT-подобного консенсуса.

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

Валидаторы Solana не имеют одинакового веса, поскольку делегированный стейк влияет на силу голоса.

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

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

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

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

Если стейк концентрируется, меньшее число субъектов может получить большее практическое влияние на выбор форка.

Если стейк широко распределён среди надёжных валидаторов, консенсус может быть более устойчивым.

Tower BFT зависит как от правил протокола, так и от здорового участия валидаторов.

Tower BFT и концепции слешинга

Слешинг — это штраф, при котором валидатор теряет стейк за доказуемо вредное поведение.

В документации Anza по Tower BFT рассматривается наказание валидаторов, нарушающих лок-ауты голосованием за форк, не являющийся потомком, во время лок-аута.

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

Концепции слешинга важны, поскольку превращают правила консенсуса в экономические стимулы.

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

В здоровой модели Proof of Stake валидаторы получают вознаграждение за честное участие и подвергаются наказанию или исключению за вредное поведение.

Tower BFT использует нарушение лок-аута как выявляемую форму некорректного голосования.

Это помогает сделать обязательства валидаторов достоверными.

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

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

Tower BFT и живучесть

Живучесть означает способность сети продолжать производить и подтверждать блоки.

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

Tower BFT стремится сбалансировать безопасность и быстрое развитие, используя временную структуру Proof of History и лок-ауты валидаторов.

В статье Solana о Tower BFT указано, что в своей специальной PBFT-подобной модели Tower BFT отдаёт предпочтение живучести перед согласованностью.

Это не означает, что согласованность игнорируется.

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

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

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

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

Tower BFT использует часы PoH и правила лок-аутов для поддержки развития сети, одновременно делая противоречивые истории затратными.

Tower BFT и PBFT

PBFT означает Practical Byzantine Fault Tolerance — практическая византийская отказоустойчивость.

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

Tower BFT вдохновлён PBFT, но адаптирует эту идею к архитектуре Solana с Proof of History.

В статье Solana о Tower BFT указано, что Solana реализует производную от PBFT с фундаментальным отличием: Proof of History обеспечивает глобальный источник времени до консенсуса.

Это означает, что Tower BFT не нужно обрабатывать тайм-ауты так же, как в традиционных PBFT-подобных раундах обмена сообщениями.

Proof of History помогает кодировать время непосредственно в реестре.

Это может снижать затраты на обмен сообщениями и задержку.

Компромисс состоит в том, что Tower BFT тесно связан с архитектурой Solana на базе PoH.

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

Он был разработан для высокопроизводительной архитектуры Solana.

Tower BFT и Proof of Stake

Tower BFT — не то же самое, что Proof of Stake.

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

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

В Solana эти концепции работают вместе.

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

Стейкеры делегируют стейк узлам валидаторов, а эти валидаторы голосуют за форки реестра.

Proof of Stake предоставляет экономический вес.

Tower BFT предоставляет логику голосования и обязательств.

Proof of History предоставляет временную структуру.

Для понимания консенсуса Solana необходимо рассматривать все три компонента вместе, а не считать одно понятие всей системой.

Tower BFT и Proof of History

Tower BFT и Proof of History часто путают, поскольку они тесно связаны.

Proof of History — это проверяемый механизм задержки и упорядочивания.

Tower BFT — механизм голосования и консенсуса, использующий временную структуру Proof of History.

Proof of History помогает валидаторам согласовать течение времени и порядок событий.

Tower BFT помогает валидаторам согласовать форк, которому следует сеть.

Простое сравнение: Proof of History — это часы, а Tower BFT — процесс голосования, использующий эти часы.

В документе Solana указано, что PoH может использоваться вместе с алгоритмами консенсуса, такими как Proof of Stake, для снижения затрат на обмен сообщениями в реплицированной машине состояний с византийской отказоустойчивостью.

Tower BFT — конкретный пример реализации этой идеи в исходной архитектуре Solana.

Называть Proof of History всем механизмом консенсуса неполно.

Также неполно считать Tower BFT независимым от Proof of History.

Tower BFT и валидаторы

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

В документации Solana для валидаторов указано, что валидаторы формируют основу сети, обрабатывая транзакции и участвуя в консенсусе.

В рамках Tower BFT валидаторы оценивают блоки, отслеживают форки и отправляют голоса.

Их голоса взвешиваются по объёму делегированного стейка.

Валидатор, который последовательно голосует корректно и остаётся онлайн, способствует надёжности сети.

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

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

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

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

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

Tower BFT и пользовательские транзакции

Большинство пользователей не взаимодействуют с Tower BFT напрямую.

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

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

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

Поэтому кошельки и приложения могут показывать различные статусы подтверждения.

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

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

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

Tower BFT является причиной, по которой эти состояния подтверждённости имеют значение на уровне протокола, а не являются только метками интерфейса.

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

Tower BFT и DeFi

Приложения децентрализованных финансов (DeFi) зависят от быстрых и надёжных расчётов.

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

Tower BFT помогает валидаторам Solana сходиться к единой истории реестра.

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

Быстрый консенсус может поддерживать удобство использования DeFi-приложений.

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

Tower BFT помогает цепочке согласовать состояние, но не гарантирует, что каждая DeFi-сделка будет прибыльной или безопасной.

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

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

Для трейдеров скорость консенсуса — лишь одна из составляющих качества исполнения.

Tower BFT и транзакции NFT

Создание, покупка, продажа, перевод и листинг невзаимозаменяемых токенов (NFT) зависят от порядка транзакций и расчётов.

Tower BFT помогает определить историю реестра, в которой фиксируются эти действия.

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

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

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

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

Tower BFT помогает валидаторам согласовать окончательное состояние после обработки транзакций сетью.

Он не определяет, ценна или легитимна ли NFT-коллекция.

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

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

Tower BFT и торговля

Tower BFT важен для трейдеров, поскольку скорость расчётов и финальность влияют на исполнение на рынке.

Быстрое подтверждение может помочь трейдерам перемещать активы, взаимодействовать с DeFi-протоколами и реагировать на изменения цены.

Однако трейдерам не следует считать быстрый консенсус гарантией исполнения без риска.

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

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

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

Tower BFT поддерживает способность сети согласовывать произошедшие события.

Он не защищает трейдеров от плохой стратегии или рыночного риска.

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

Консенсус — это инфраструктура расчётов, а не торговый сигнал.

Tower BFT и уровни подтверждённости

Уровни подтверждённости — это ориентированные на пользователя способы описать, насколько сильно подтверждена транзакция или блок.

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

Tower BFT способствует подтверждённости посредством голосов, лок-аутов и корней.

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

Финализированная транзакция лучше защищена от отката, чем только что обнаруженная транзакция.

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

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

Крупный финансовый расчёт может нуждаться в более сильной финальности.

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

Tower BFT — консенсусная логика, придающая более глубокой подтверждённости смысл.

Tower BFT и производительность сети

Архитектура Solana нацелена на высокую производительность, и Tower BFT является одной из её частей.

Используя Proof of History в качестве источника времени, Tower BFT может сокращать часть затрат на обмен сообщениями, характерных для старых BFT-подобных моделей.

Меньшие накладные расходы могут помогать сети быстрее принимать решения при благоприятных условиях.

Однако производительность зависит не только от консенсуса.

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

Tower BFT работает вместе с другими компонентами Solana, отвечающими за производство блоков, распространение данных, исполнение и хранение реестра.

Узкое место в одной части системы всё равно может повлиять на пользовательский опыт.

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

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

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

Tower BFT и стоимость отката

Стоимость отката — это стоимость или сложность отмены ранее принятого блока.

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

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

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

Tower BFT усиливает старые обязательства через накопление лок-аутов.

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

В системе Proof of Stake экономические последствия могут делать такое поведение затратным.

Стоимость отката — не то же самое, что простой счётчик блоков.

Она зависит от голосов валидаторов, веса стейка, глубины лок-аутов и правил протокола.

Понимание стоимости отката помогает объяснить, почему финальность усиливается со временем.

Tower BFT и предположения безопасности

Tower BFT зависит от нескольких предположений безопасности.

Он предполагает, что достаточное число валидаторов с весом стейка честно соблюдает протокол.

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

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

Он предполагает, что временная структура Proof of History проверяема и полезна для координации поведения валидаторов.

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

Ни один механизм консенсуса не является магией.

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

Tower BFT был создан для исходных целей производительности Solana.

Его сильные и слабые стороны следует оценивать в контексте архитектуры Solana, а не как универсальную BFT-систему.

Tower BFT и Alpenglow

Alpenglow — предложенное крупное изменение консенсусной архитектуры Solana, актуальное при современном обсуждении Tower BFT.

В официальном предложении SIMD-0326 Alpenglow указано, что оно заменяет основной протокол консенсуса — текущую архитектуру на основе Proof of History и TowerBFT — на Alpenglow.

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

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

Это не означает, что пользователи должны считать Tower BFT неактуальным.

Tower BFT остаётся важным, поскольку объясняет исходную архитектуру консенсуса Solana и модель, которую предполагается заменить с помощью Alpenglow.

Понимание Tower BFT помогает пользователям понять значение Alpenglow.

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

Для точности глоссария Tower BFT следует описывать с учётом того, что дорожная карта консенсуса Solana развивается.

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

Преимущества Tower BFT

Первое преимущество Tower BFT состоит в использовании Proof of History как общего временного ориентира.

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

Второе преимущество заключается в том, что лок-ауты делают голоса валидаторов значимыми.

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

Третье преимущество — накопленные лок-ауты позволяют оценивать стоимость отката.

Старые блоки с более глубокой подтверждённостью сложнее отменить.

Четвёртое преимущество — Tower BFT соответствует высокопроизводительной архитектуре Solana.

Он был разработан для поддержки быстрого подтверждения блоков и координации валидаторов.

Пятое преимущество — голосование с весом стейка связывает влияние на консенсус с делегированным стейком.

Это даёт экономическому уровню прямую роль в выборе форка.

Ограничения Tower BFT

Первое ограничение Tower BFT — сложность.

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

Второе ограничение — финальность не является мгновенной.

Подтверждённость усиливается со временем по мере накопления голосов и лок-аутов.

Третье ограничение — модель тесно связана с архитектурой Solana на базе Proof of History.

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

Четвёртое ограничение — качество консенсуса зависит от производительности валидаторов и распределения стейка.

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

Пятое ограничение — собственное предложение Solana Alpenglow указывает на опасения относительно производительности и доказательства безопасности устаревшей модели TowerBFT.

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

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

Первое заблуждение — считать Tower BFT и Proof of History одним и тем же.

Proof of History является механизмом времени и упорядочивания, тогда как Tower BFT — механизмом консенсуса на основе голосов и лок-аутов.

Второе заблуждение — считать Tower BFT тем же самым, что Proof of Stake.

Proof of Stake предоставляет экономическое влияние с весом стейка, тогда как Tower BFT организует голоса и лок-ауты.

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

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

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

Лок-ауты Tower BFT ограничивают голосование валидаторов за противоречащие форки в периоды действия обязательств.

Пятое заблуждение — считать, что для использования Solana пользователям нужно понимать каждую деталь Tower BFT.

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

Рекомендации для пользователей

Используйте надёжные кошельки и приложения, которые ясно отображают статус транзакций.

Ожидайте более сильной подтверждённости при перемещении активов на крупные суммы.

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

При необходимости проверяйте статус транзакции через надёжные обозреватели блокчейна или интерфейсы приложений.

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

Не отправляйте повторные транзакции, не проверив, была ли обработана первая.

Используйте контроль проскальзывания при взаимодействии с DeFi-протоколами.

Держите достаточное количество SOL для комиссий за транзакции при использовании приложений на базе Solana.

Не считайте скорость консенсуса гарантией торговой прибыли.

Учитывайте финальность как часть более широкого управления криптовалютными рисками.

Рекомендации для разработчиков

Выбирайте уровни подтверждённости с учётом риска и ценности действия в приложении.

Не считайте каждую наблюдаемую транзакцию одинаково финальной.

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

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

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

При необходимости используйте надёжных инфраструктурных провайдеров и несколько источников данных.

Проектируйте DeFi-приложения с учётом проскальзывания, изменений состояния и времени подтверждения.

Тестируйте поведение приложений в условиях перегрузки и задержек подтверждения.

Следите за обновлениями консенсуса Solana, включая изменения, связанные с Alpenglow.

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

FAQ

Что такое Tower BFT простыми словами?

Tower BFT — это исходная BFT-подобная система голосования валидаторов Solana, использующая временную структуру Proof of History, чтобы помочь валидаторам согласовать корректную цепочку.

Является ли Tower BFT тем же самым, что Proof of History?

Нет. Proof of History предоставляет проверяемую структуру времени и упорядочивания, а Tower BFT использует её для голосов валидаторов и лок-аутов.

Является ли Tower BFT тем же самым, что Proof of Stake?

Нет. Proof of Stake обеспечивает экономический уровень с весом стейка, а Tower BFT обеспечивает логику голосования и выбора форка.

Почему он называется Tower BFT?

Он называется Tower BFT, поскольку голоса валидаторов накапливаются с возрастающими лок-аутами, создавая башнеподобную структуру обязательств.

Что такое лок-аут в Tower BFT?

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

Что такое слот в Tower BFT?

Слот — это единица времени Solana для планирования лидеров, производства блоков, голосования и измерения лок-аутов.

Какую роль валидаторы играют в Tower BFT?

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

Что делает Tower BFT во время форков?

Tower BFT помогает валидаторам оценивать конкурирующие форки и принимать обязательство по одному форку с помощью голосов с весом стейка и лок-аутов.

Обеспечивает ли Tower BFT мгновенную финальность?

Нет. Финальность усиливается со временем по мере накопления голосов и углубления лок-аутов.

Почему Proof of History помогает Tower BFT?

Proof of History предоставляет Tower BFT общий временной ориентир, который помогает обеспечивать тайм-ауты и лок-ауты с меньшими затратами на обмен сообщениями.

Что такое стоимость отката в Tower BFT?

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

Могут ли пользователи напрямую взаимодействовать с Tower BFT?

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

Почему пользователям DeFi следует учитывать Tower BFT?

Пользователям DeFi следует учитывать Tower BFT, поскольку консенсус влияет на порядок транзакций, силу подтверждения, уверенность в расчётах и надёжность приложений.

Как Alpenglow связан с Tower BFT?

Alpenglow — это предложенная переработка консенсуса Solana, которая заменит текущий протокол на основе Proof of History и TowerBFT более новой архитектурой.

Важно ли по-прежнему понимать Tower BFT?

Да. Tower BFT важен, поскольку объясняет исходную архитектуру консенсуса Solana и базовую модель, с которой сравниваются новые предложения по консенсусу.

Заключение

Tower BFT — это оптимизированный для Proof of History механизм голосования Solana с византийской отказоустойчивостью.

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

Proof of History предоставляет общую временную структуру, Proof of Stake предоставляет экономический вес голосов, а Tower BFT предоставляет консенсусную логику голосования и лок-аутов.

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

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

Tower BFT важен для пользователей, разработчиков, валидаторов, трейдеров, DeFi-протоколов и NFT-приложений, поскольку консенсус влияет на расчёты, упорядочивание, финальность и надёжность.

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

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

По мере развития дорожной карты консенсуса Solana Tower BFT остаётся важнейшим термином для понимания того, как Solana изначально объединила Proof of History с BFT-подобным голосованием валидаторов.

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