Tower BFT

Tower BFT là gì?

Tower BFT là cơ chế bỏ phiếu đồng thuận Khả năng chịu lỗi Byzantine được tối ưu hóa cho Proof of History của Solana.

Trong crypto, Tower BFT được hiểu là hệ thống giúp validator Solana bỏ phiếu cho fork chính xác, xây dựng mức độ cam kết đối với các block và khiến việc rollback ngày càng tốn kém theo thời gian.

Tài liệu chính thức về Anza Tower BFT giải thích rằng Solana tạo ra một nguồn thời gian thông qua Proof of History và sử dụng slot làm đơn vị thời gian.

Mỗi slot có thể có một leader được chỉ định, người có thể tạo block.

Sau đó, các validator bỏ phiếu cho fork mà họ tin rằng sẽ trở thành chuỗi hợp lệ nặng nhất.

Tower BFT không phải là Proof of History.

Proof of History cung cấp đồng hồ mật mã và cấu trúc sắp xếp thứ tự, trong khi Tower BFT sử dụng cấu trúc thời gian này để tổ chức phiếu bầu của validator, lockout, lựa chọn fork và mức độ cam kết.

Sách trắng Solana chính thức mô tả Proof of History là bằng chứng để xác minh thứ tự và sự trôi qua của thời gian giữa các sự kiện.

Tower BFT xây dựng trên ý tưởng này bằng cách cho phép validator bỏ phiếu với các lockout dựa trên thời gian, được đo bằng slot.

Trong một thuật ngữ crypto, Tower BFT nên được hiểu là lớp đồng thuận kiểu BFT ban đầu của Solana, sử dụng thời gian Proof of History để giảm chi phí phối hợp và hỗ trợ xác nhận block nhanh.

Vì sao Tower BFT quan trọng?

Tower BFT quan trọng vì đồng thuận là quá trình cho phép một blockchain thống nhất về một lịch sử dùng chung.

Nếu không có đồng thuận, các validator có thể bất đồng về giao dịch nào đã xảy ra, số dư nào hợp lệ và block nào đáng tin cậy.

Solana được thiết kế để có thông lượng cao và độ trễ thấp, vì vậy thiết kế đồng thuận cần tránh việc chờ đợi không cần thiết và trao đổi quá nhiều thông điệp.

Tower BFT hỗ trợ mục tiêu này bằng cách sử dụng Proof of History làm tham chiếu thời gian chung trước khi đạt được đồng thuận hoàn toàn.

Bài viết chính thức về Solana Tower BFT mô tả Tower BFT là một cách triển khai tùy chỉnh của PBFT, tận dụng Proof of History như một đồng hồ trước khi đồng thuận để giảm chi phí truyền thông điệp và độ trễ.

Điều này quan trọng với người dùng vì đồng thuận ảnh hưởng đến việc xác nhận giao dịch, kỳ vọng về tính cuối cùng, hành vi validator và độ tin cậy của mạng.

Điều này quan trọng với validator vì quyết định bỏ phiếu có thể tạo lockout, hạn chế các lựa chọn bỏ phiếu trong tương lai.

Điều này quan trọng với nhà phát triển vì độ tin cậy của ứng dụng phụ thuộc vào việc hiểu cách hoạt động của các trạng thái đã xác nhận, đã hoàn tất và liên quan đến fork.

Điều này quan trọng với trader vì tính cuối cùng nhanh và quá trình thanh toán ổn định có thể ảnh hưởng đến việc nạp, rút trên sàn, hoạt động DeFi và rủi ro arbitrage.

Vì vậy, Tower BFT không chỉ là chi tiết dành cho validator mà còn là một phần của hạ tầng thị trường rộng lớn hơn đằng sau hoạt động crypto trên Solana.

BFT nghĩa là gì?

BFT là viết tắt của Byzantine Fault Tolerance, hay Khả năng chịu lỗi Byzantine.

Lỗi Byzantine là dạng lỗi trong đó một bên tham gia có thể hoạt động không thể dự đoán, không chính xác hoặc có chủ đích xấu.

Trong các hệ thống blockchain, điều này có thể có nghĩa là validator ngoại tuyến, chậm, không trung thực, bỏ phiếu hai lần, kiểm duyệt hoặc tạo ra các thông điệp mâu thuẫn.

Một hệ thống đồng thuận BFT cố gắng duy trì an toàn cho mạng ngay cả khi một số bên tham gia gặp lỗi.

Tính an toàn nghĩa là các bên tham gia trung thực không nên hoàn tất các lịch sử mâu thuẫn.

Tính sống động nghĩa là mạng nên tiếp tục tiến triển khi đủ số bên tham gia trung thực có thể giao tiếp.

Tower BFT thuộc nhóm thiết kế đồng thuận kiểu BFT vì tập trung vào bỏ phiếu validator, lựa chọn fork, lockout và mức độ cam kết trong điều kiện có thể xảy ra lỗi.

Đây không phải là biểu quyết đa số đơn giản theo số lượng validator.

Solana sử dụng biểu quyết theo trọng số stake, nghĩa là validator có nhiều stake được ủy quyền hơn sẽ có trọng số bỏ phiếu lớn hơn.

Trang validator Solana chính thức giải thích rằng validator phát lại sổ cái, gửi phiếu bầu đến các tài khoản bỏ phiếu và cluster sử dụng phiếu bầu theo trọng số stake để chọn một block khi xuất hiện fork.

Tower BFT và Proof of History

Proof of History là nền tảng thời gian khiến Tower BFT khác với nhiều hệ thống BFT truyền thống.

Các giao thức BFT truyền thống thường yêu cầu validator trao đổi nhiều thông điệp hơn để thống nhất về timeout và tiến qua các view hoặc vòng.

Thiết kế của Solana sử dụng một chuỗi tính toán có thể xác minh để tạo hồ sơ chung về thời gian và thứ tự.

Sách trắng Solana cho biết Proof of History có thể mã hóa sự trôi qua của thời gian không cần tin cậy vào một sổ cái chỉ có thể ghi thêm.

Điều này cho Tower BFT cách đo lockout của phiếu bầu bằng slot, thay vì chỉ dựa vào đồng hồ cục bộ và đàm phán lặp lại.

Nói đơn giản, Proof of History cung cấp cho mạng một dòng thời gian chung, còn Tower BFT sử dụng dòng thời gian đó để tổ chức các phiếu bầu đồng thuận.

Đây là lý do Tower BFT thường được mô tả là BFT tối ưu hóa cho PoH.

Cấu trúc PoH giống đồng hồ giúp validator biết khi nào các cam kết bỏ phiếu nhất định hết hạn.

Nó cũng giúp giao thức giảm chi phí giao tiếp vì timeout có thể được suy ra từ cấu trúc thời gian của sổ cái.

Đối với người dùng, kết quả là mô hình đồng thuận được thiết kế để hỗ trợ xác nhận nhanh hơn các thiết kế đồng thuận cũ cần nhiều thông điệp.

Tower BFT và slot

Slot là đơn vị thời gian của Solana dành cho việc tạo block và bỏ phiếu validator.

Trong Tower BFT, lockout và cam kết bỏ phiếu được đo bằng slot.

Tài liệu Anza Tower BFT cho biết mỗi slot có một leader được chỉ định có thể tạo block.

Leader có thể không tạo được block, vì vậy một số slot có thể không chứa block.

Validator quan sát block và bỏ phiếu cho fork mà họ tin sẽ trở thành fork hợp lệ nặng nhất.

Vì slot tạo ra một cấu trúc có thể dự đoán, validator có thể phối hợp trên một dòng thời gian chung.

Một block được liên kết với một slot và phiếu bầu có thể tham chiếu các block trên một fork.

Điều này cho phép Tower BFT kết nối thời gian, luân phiên leader, lựa chọn fork và cam kết validator thành một quy trình.

Thời gian dựa trên slot cũng quan trọng đối với tính cuối cùng vì các phiếu bầu lặp lại trên những slot sau làm tăng độ cam kết đối với các slot trước đó.

Validator càng bỏ phiếu nhiều cho các block hậu duệ, việc từ bỏ fork trước đó một cách an toàn càng khó hơn.

Tower BFT và phiếu bầu của validator

Phiếu bầu validator là hành động cốt lõi trong Tower BFT.

Một phiếu bầu cho biết block hoặc fork nào được validator ủng hộ.

Tài liệu Anza Tower BFT mô tả phiếu bầu được validator ký và hình thành dựa trên danh tính validator cùng hash block được bỏ phiếu.

Phiếu bầu không chỉ là ý kiến.

Chúng tạo ra lockout, hạn chế những gì validator có thể bỏ phiếu tiếp theo.

Điều này quan trọng vì validator không nên có thể tự do bỏ phiếu cho một fork rồi ngay lập tức chuyển sang fork mâu thuẫn mà không phải chịu chi phí.

Nếu việc chuyển đổi không tốn chi phí, validator có thể hành động theo cơ hội và làm suy yếu niềm tin vào sổ cái.

Tower BFT biến việc bỏ phiếu thành một cam kết.

Cam kết này mạnh hơn khi có thêm nhiều phiếu bầu xếp chồng trên cùng fork.

Tên gọi “Tower” xuất phát từ cấu trúc cam kết xếp chồng này.

Lockout trong Tower BFT là gì?

Lockout là khoảng thời gian mà validator bị hạn chế bỏ phiếu cho một fork mâu thuẫn.

Tài liệu Anza Tower BFT cho biết lockout được đo bằng slot và ngăn validator bỏ phiếu cho fork khác trong khoảng thời gian đó.

Mục đích của lockout là buộc validator chịu chi phí cơ hội khi cam kết với fork mà họ đã ủng hộ.

Ví dụ, nếu validator bỏ phiếu cho một block trên một fork, validator đó không thể ngay lập tức bỏ phiếu cho fork cạnh tranh không bao gồm block đó làm tổ tiên.

Nếu validator muốn đổi hướng, họ có thể phải chờ lockout hết hạn.

Điều này khiến các phiếu bầu có ý nghĩa hơn vì chúng mang theo hệ quả trong tương lai.

Lockout cũng giúp client ước tính chi phí rollback.

Một block cũ hơn với hỗ trợ lockout sâu hơn sẽ khó rollback hơn vì validator sẽ cần vi phạm hoặc từ bỏ những cam kết lớn hơn.

Đây là một trong những cách chính Tower BFT biến phiếu bầu ngắn hạn thành niềm tin thanh toán mạnh hơn.

Nói đơn giản, lockout khiến validator đặt cam kết có trọng số thời gian đằng sau phiếu bầu của họ.

Cách lockout xếp chồng

Tower BFT sử dụng một ngăn xếp các phiếu bầu gần đây và lockout tương ứng.

Khi validator tiếp tục bỏ phiếu cho các block hậu duệ của phiếu bầu trước, phiếu bầu trước đó sẽ được cam kết sâu hơn.

Các phiếu bầu liên tiếp có thể tăng thời lượng lockout và làm các cam kết cũ mạnh hơn.

Điều này tạo cấu trúc cam kết bỏ phiếu giống một tòa tháp.

Một phiếu bầu mới có thể có lockout ngắn.

Một phiếu bầu cũ có nhiều phiếu bầu hậu duệ về sau đứng sau sẽ có lockout mạnh hơn.

Cấu trúc này giúp validator dần chuyển từ hỗ trợ tạm thời sang cam kết mạnh hơn.

Nó cũng giúp client đánh giá chi phí đảo ngược một block.

Tháp càng sâu, validator càng tốn kém khi vi phạm các cam kết.

Đây là lý do Tower BFT liên hệ chặt chẽ với hành vi cam kết và tính cuối cùng của Solana.

Tower BFT và lựa chọn fork

Fork xảy ra khi sổ cái phân nhánh thành nhiều chuỗi slot có thể có.

Fork có thể xảy ra do độ trễ mạng, leader bỏ lỡ, block cạnh tranh hoặc validator nhìn thấy dữ liệu tại các thời điểm khác nhau.

Tài liệu chính thức của Anza về quản lý fork giải thích rằng sổ cái được phép fork tại ranh giới slot và validator duy trì trạng thái cho từng fork.

Tower BFT giúp validator đánh giá các fork này và cuối cùng chọn một fork.

Validator bỏ phiếu cho fork mà họ tin là nặng nhất và hợp lệ.

Phiếu bầu theo trọng số stake giúp mạng hội tụ về một fork.

Lockout ngăn validator chuyển đổi thường xuyên giữa các fork mâu thuẫn.

Điều này khiến lựa chọn fork ổn định hơn theo thời gian.

Một fork có phiếu bầu theo trọng số stake mạnh hơn và lockout sâu hơn sẽ khó bị thay thế hơn.

Với người dùng, đây là một phần lý do giao dịch trở nên an toàn hơn khi nhận được cam kết mạnh hơn.

Tower BFT và root

Root là một slot đã được cam kết đủ sâu để validator xem là vĩnh viễn khi quản lý fork cục bộ.

Tài liệu Anza về quản lý fork giải thích root là slot đã đạt độ sâu lockout tối đa.

Khi root được thiết lập, validator có thể loại bỏ các fork không bắt nguồn từ root đó.

Điều này cải thiện hiệu suất vì validator không cần lưu mọi fork cũ trong bộ nhớ hoạt động mãi mãi.

Việc thiết lập root cũng giúp validator tập trung vào lịch sử chuỗi đã tích lũy đủ cam kết.

Trên thực tế, root quan trọng vì giúp biến cây fork phức tạp thành lịch sử chuỗi có thể quản lý.

Root không có nghĩa mọi rủi ro về mặt lý thuyết đều biến mất.

Nó nghĩa là validator coi rollback là đủ tốn kém hoặc phi thực tế theo các giả định thông thường.

Rooting kết nối bảo mật đồng thuận với hiệu suất validator.

Nếu không có cơ chế loại bỏ và rooting, việc quản lý fork có thể trở nên tốn kém và kém hiệu quả theo thời gian.

Tower BFT và tính cuối cùng

Tính cuối cùng nghĩa là một giao dịch hoặc block được xem là cực kỳ khó hoặc gần như không thể đảo ngược theo các giả định của giao thức.

Tower BFT hỗ trợ tính cuối cùng thông qua các phiếu bầu lặp lại theo trọng số stake và lockout ngày càng tăng.

Khi validator bỏ phiếu cho các block hậu duệ, các block trước đó ngày càng được bảo vệ bởi cam kết lockout.

Điều này mang lại cho người dùng và ứng dụng mức độ tin cậy tăng dần khi nhiều slot được xây dựng trên giao dịch.

Tính cuối cùng không chỉ là nhãn trên giao diện người dùng.

Đây là thuộc tính đồng thuận liên quan đến phiếu bầu validator, trọng số stake, độ sâu lockout và lựa chọn fork.

Trong các hệ thống kiểu Solana, giao dịch có thể hiển thị là đã xử lý trước khi đạt mức cam kết mạnh nhất.

Ứng dụng nên chọn mức cam kết dựa trên mức độ chấp nhận rủi ro.

Một ví hiển thị giao dịch rủi ro thấp có thể chấp nhận xác nhận sớm hơn, trong khi thanh toán giá trị cao có thể chờ tính cuối cùng mạnh hơn.

Tower BFT là cơ chế đằng sau quá trình chuyển dần từ việc được đưa vào tạm thời đến cam kết mạnh hơn này.

Tower BFT và siêu đa số

Sự ủng hộ của siêu đa số rất quan trọng trong đồng thuận kiểu BFT.

Trong các hệ thống theo trọng số stake, siêu đa số thường chỉ tỷ lệ lớn trong tổng stake đang hoạt động ủng hộ cùng một chuỗi hoặc quyết định.

Validator Solana không có trọng số ngang nhau vì stake được ủy quyền ảnh hưởng đến quyền biểu quyết.

Điều này nghĩa là validator nhỏ và validator lớn đều có thể bỏ phiếu, nhưng phiếu của họ không có cùng trọng số stake.

Trang validator Solana giải thích rằng cluster sử dụng phiếu bầu theo trọng số stake để chọn block khi xuất hiện fork.

Thiết kế theo trọng số stake này giúp gắn ảnh hưởng trong đồng thuận với stake chịu rủi ro.

Nó cũng có nghĩa phân bổ stake ảnh hưởng đến tính phi tập trung và khả năng chống chịu của đồng thuận.

Nếu stake tập trung, ít thực thể hơn có thể có ảnh hưởng thực tế lớn hơn đến lựa chọn fork.

Nếu stake được phân bổ rộng giữa các validator đáng tin cậy, đồng thuận có thể có khả năng chống chịu tốt hơn.

Tower BFT phụ thuộc vào cả quy tắc giao thức lẫn sự tham gia lành mạnh của validator.

Tower BFT và khái niệm slashing

Slashing là hình phạt khiến validator mất stake vì hành vi gây hại có thể chứng minh được.

Tài liệu Anza Tower BFT đề cập đến việc trừng phạt validator vi phạm lockout khi bỏ phiếu cho một fork không phải hậu duệ trong thời gian lockout.

Ý tưởng cốt lõi là validator nên chịu hậu quả kinh tế đối với các phiếu bầu mâu thuẫn đe dọa tính nhất quán.

Các khái niệm slashing quan trọng vì chúng biến quy tắc đồng thuận thành động lực kinh tế.

Nếu validator có thể bỏ phiếu hai lần mà không bị phạt, giao thức sẽ bảo vệ yếu hơn trước các lịch sử mâu thuẫn.

Trong thiết kế Proof of Stake lành mạnh, validator được thưởng vì tham gia trung thực và bị phạt hoặc loại trừ vì hành vi gây hại.

Tower BFT sử dụng khái niệm vi phạm lockout như một dạng hành vi bỏ phiếu xấu có thể phát hiện.

Điều này giúp các cam kết validator trở nên đáng tin cậy.

Người dùng thường không trực tiếp thấy cơ chế slashing trong ví.

Tuy nhiên, sự tồn tại của các quy tắc validator có thể thực thi là một phần lý do đồng thuận theo trọng số stake có thể bảo vệ tính toàn vẹn của sổ cái.

Tower BFT và tính sống động

Tính sống động nghĩa là mạng có thể tiếp tục tạo và xác nhận block.

Một hệ thống đồng thuận an toàn nhưng không bao giờ tiến triển sẽ không hữu ích cho thanh toán, giao dịch, DeFi hoặc ứng dụng.

Tower BFT cố gắng cân bằng tính an toàn với tốc độ tiến triển bằng cách sử dụng thời gian Proof of History và lockout validator.

Bài viết Solana Tower BFT cho biết Tower BFT ưu tiên tính sống động hơn tính nhất quán trong thiết kế tùy chỉnh kiểu PBFT.

Điều này không có nghĩa tính nhất quán bị bỏ qua.

Nó nghĩa là thiết kế đưa ra các lựa chọn nhằm duy trì hoạt động của mạng trong điều kiện thực tế.

Người dùng crypto quan tâm đến tính sống động vì một mạng đang hoạt động có thể xử lý chuyển tiền, swap, lệnh, hoạt động staking và tương tác ứng dụng.

Validator quan tâm đến tính sống động vì đồng thuận bị đình trệ có thể ảnh hưởng đến phần thưởng, danh tiếng và độ tin cậy mạng.

Nhà phát triển quan tâm đến tính sống động vì ứng dụng cần quá trình xử lý giao dịch có thể dự đoán.

Tower BFT sử dụng đồng hồ PoH và quy tắc lockout để hỗ trợ tiến triển, đồng thời vẫn khiến các lịch sử mâu thuẫn trở nên tốn kém.

Tower BFT và PBFT

PBFT là viết tắt của Practical Byzantine Fault Tolerance.

PBFT là phương pháp đồng thuận cổ điển sử dụng giao tiếp có cấu trúc giữa các bản sao để thống nhất về yêu cầu bất chấp lỗi Byzantine.

Tower BFT lấy cảm hứng từ PBFT nhưng điều chỉnh ý tưởng này cho kiến trúc Proof of History của Solana.

Bài viết Solana Tower BFT cho biết Solana triển khai một dẫn xuất của PBFT, với khác biệt cơ bản là Proof of History cung cấp nguồn thời gian toàn cục trước khi đồng thuận.

Điều này nghĩa là Tower BFT không cần xử lý timeout giống các vòng truyền thông điệp kiểu PBFT truyền thống.

Proof of History giúp mã hóa thời gian vào chính sổ cái.

Điều này có thể giảm chi phí truyền thông điệp và độ trễ.

Đánh đổi là Tower BFT gắn chặt với kiến trúc dựa trên PoH của Solana.

Đây không phải mô-đun đồng thuận chung có thể cắm và chạy giống nhau trên mọi blockchain.

Nó được thiết kế xoay quanh kiến trúc hiệu suất cao của Solana.

Tower BFT và Proof of Stake

Tower BFT không phải là Proof of Stake.

Proof of Stake mô tả cách ảnh hưởng validator và bảo mật kinh tế gắn với token đã stake.

Tower BFT mô tả cách validator sử dụng phiếu bầu theo trọng số stake, lockout và lựa chọn fork để đạt đồng thuận.

Trên Solana, các khái niệm này phối hợp với nhau.

Validator tham gia đồng thuận và stake được ủy quyền cho họ ảnh hưởng đến trọng số phiếu bầu.

Người stake ủy quyền stake cho node validator và các validator này bỏ phiếu cho fork của sổ cái.

Proof of Stake cung cấp trọng số kinh tế.

Tower BFT cung cấp logic bỏ phiếu và cam kết.

Proof of History cung cấp cấu trúc thời gian.

Để hiểu đồng thuận Solana cần nhìn cả ba thành phần, thay vì xem một cụm từ là toàn bộ hệ thống.

Tower BFT và Proof of History

Tower BFT và Proof of History thường bị nhầm lẫn vì chúng liên kết chặt chẽ.

Proof of History là cơ chế trì hoãn có thể xác minh và sắp xếp thứ tự.

Tower BFT là cơ chế bỏ phiếu và đồng thuận sử dụng thời gian Proof of History.

Proof of History giúp validator thống nhất về sự trôi qua của thời gian và thứ tự sự kiện.

Tower BFT giúp validator thống nhất về fork cần theo.

Một cách so sánh đơn giản là Proof of History là đồng hồ, còn Tower BFT là quy trình bỏ phiếu dùng đồng hồ đó.

Sách trắng Solana nêu rằng PoH có thể được sử dụng cùng các thuật toán đồng thuận như Proof of Stake để giảm chi phí truyền thông điệp trong máy trạng thái sao chép có Khả năng chịu lỗi Byzantine.

Tower BFT là một ví dụ cụ thể cho ý tưởng này trong thiết kế ban đầu của Solana.

Gọi Proof of History là toàn bộ cơ chế đồng thuận là chưa đầy đủ.

Gọi Tower BFT độc lập với Proof of History cũng chưa đầy đủ.

Tower BFT và validator

Validator là những bên tham gia mạng xử lý giao dịch, phát lại sổ cái và bỏ phiếu trong đồng thuận.

Tài liệu validator Solana cho biết validator là xương sống của mạng bằng cách xử lý giao dịch và tham gia đồng thuận.

Trong Tower BFT, validator đánh giá block, theo dõi fork và gửi phiếu bầu.

Phiếu bầu của họ được tính trọng số theo stake được ủy quyền.

Validator liên tục bỏ phiếu chính xác và duy trì trực tuyến góp phần vào độ tin cậy của mạng.

Validator ngoại tuyến hoặc kết nối kém có thể bỏ lỡ phiếu bầu và giảm hiệu quả.

Validator bỏ phiếu sai hoặc vi phạm kỳ vọng lockout có thể đe dọa tính an toàn của đồng thuận.

Đây là lý do hiệu suất validator, khả năng kết nối, chất lượng phần mềm và kỷ luật vận hành đều quan trọng.

Người dùng stake SOL gián tiếp tham gia đồng thuận bằng cách ủy quyền cho validator.

Lựa chọn validator cẩn thận có thể hỗ trợ tính phi tập trung và sức khỏe mạng.

Tower BFT và giao dịch người dùng

Hầu hết người dùng không tương tác trực tiếp với Tower BFT.

Người dùng gửi giao dịch từ ví hoặc ứng dụng, sau đó validator xử lý giao dịch qua mạng.

Nếu giao dịch được đưa vào block, validator có thể bỏ phiếu cho fork của block đó.

Khi phiếu bầu tích lũy và lockout sâu hơn, giao dịch nhận được cam kết mạnh hơn.

Đây là lý do ví và ứng dụng có thể hiển thị các trạng thái xác nhận khác nhau.

Giao dịch có thể xuất hiện nhanh, nhưng tính cuối cùng mạnh hơn đến từ tiến trình đồng thuận bổ sung.

Đối với chuyển tiền hằng ngày giá trị nhỏ, xác nhận sớm có thể đủ cho một số trường hợp sử dụng.

Với thanh toán giá trị cao, ứng dụng có thể chờ cam kết mạnh hơn.

Tower BFT là lý do các trạng thái cam kết đó có ý nghĩa ở cấp giao thức, thay vì chỉ là nhãn giao diện.

Người dùng được hưởng lợi khi đồng thuận hoạt động tốt vì giao dịch trở nên đáng tin cậy và dễ tin tưởng hơn.

Tower BFT và DeFi

Ứng dụng DeFi phụ thuộc vào quá trình thanh toán nhanh và đáng tin cậy.

Một thao tác swap, cho vay, thanh lý hoặc cập nhật thanh khoản chỉ hữu ích nếu mạng có thể thống nhất về thứ tự và kết quả của nó.

Tower BFT giúp validator Solana hội tụ về lịch sử sổ cái chung.

Điều này ảnh hưởng đến DeFi vì thứ tự giao dịch có thể tác động đến giá, tài sản thế chấp, thanh lý và arbitrage.

Đồng thuận nhanh có thể hỗ trợ trải nghiệm DeFi phản hồi tốt.

Tuy nhiên, người dùng DeFi vẫn nên hiểu rằng xử lý nhanh không loại bỏ rủi ro hợp đồng thông minh, trượt giá, rủi ro oracle, rủi ro thanh khoản hoặc rủi ro giao dịch thất bại.

Tower BFT giúp chuỗi thống nhất về trạng thái, nhưng không đảm bảo mọi giao dịch DeFi đều có lợi nhuận hoặc an toàn.

Ứng dụng vẫn phải xử lý mức xác nhận, thử lại, biến động thị trường và biện pháp kiểm soát rủi ro.

Với nhà phát triển, giả định đồng thuận là một phần trong thiết kế ứng dụng.

Với trader, tốc độ đồng thuận chỉ là một phần của chất lượng khớp lệnh.

Tower BFT và giao dịch NFT

Các hoạt động mint, mua, bán, chuyển và niêm yết NFT phụ thuộc vào thứ tự giao dịch và thanh toán.

Tower BFT giúp xác định lịch sử sổ cái ghi lại các hoạt động này.

Trong các đợt mint NFT phổ biến, nhiều người dùng có thể cạnh tranh để gửi giao dịch nhanh.

Đồng thuận vẫn phải quyết định giao dịch nào được đưa vào và theo thứ tự nào.

Con đường đồng thuận nhanh có thể cải thiện trải nghiệm người dùng, nhưng không đảm bảo mọi giao dịch đều thành công.

Giao dịch mint NFT có thể thất bại nếu nguồn cung cạn, phí không đủ, chỉ dẫn sai hoặc chương trình từ chối hành động.

Tower BFT giúp validator thống nhất về trạng thái cuối cùng sau khi mạng xử lý giao dịch.

Nó không xác định bộ sưu tập NFT có giá trị hoặc hợp pháp hay không.

Người dùng nên xác minh nguồn bộ sưu tập chính thức, địa chỉ hợp đồng và bối cảnh marketplace.

Bảo mật đồng thuận hỗ trợ thanh toán, nhưng không thay thế cho quá trình thẩm định.

Tower BFT và giao dịch

Trader quan tâm đến Tower BFT vì tốc độ thanh toán và tính cuối cùng ảnh hưởng đến việc thực thi trên thị trường.

Xác nhận nhanh có thể giúp trader chuyển tài sản, tương tác với giao thức DeFi và phản ứng với thay đổi giá.

Tuy nhiên, trader không nên xem đồng thuận nhanh là bảo đảm thực thi không rủi ro.

Kết quả giao dịch vẫn phụ thuộc vào thanh khoản, trượt giá, phí, định tuyến lệnh, biến động thị trường và thiết kế ứng dụng.

Một giao dịch có thể được xử lý nhanh nhưng vẫn tạo giao dịch bất lợi nếu thị trường di chuyển trước khi khớp lệnh.

Một giao dịch có thể được xác nhận nhưng vẫn thất bại vì điều kiện hợp đồng thông minh không được đáp ứng.

Tower BFT hỗ trợ khả năng của mạng trong việc thống nhất về những gì đã xảy ra.

Nó không bảo vệ trader khỏi chiến lược kém hoặc rủi ro thị trường.

Đối với giao dịch nghiêm túc, người dùng nên kết hợp nhận thức về đồng thuận với mô phỏng giao dịch, giới hạn trượt giá và quản lý rủi ro.

Đồng thuận là hạ tầng thanh toán, không phải tín hiệu giao dịch.

Tower BFT và các mức cam kết

Các mức cam kết là cách hướng đến người dùng để mô tả mức độ xác nhận của giao dịch hoặc block.

Dù giao diện có thể dùng các nhãn khác nhau, ý tưởng nền tảng là cam kết validator nhiều hơn đồng nghĩa mức độ tin cậy cao hơn.

Tower BFT đóng góp vào cam kết thông qua phiếu bầu, lockout và root.

Một giao dịch vừa được xử lý có thể có ít cam kết hơn giao dịch nằm sau nhiều phiếu bầu về sau.

Giao dịch đã hoàn tất được bảo vệ khỏi rollback mạnh hơn một giao dịch mới được quan sát.

Nhà phát triển ứng dụng nên chọn mức cam kết dựa trên giá trị và rủi ro của hành động.

Một hành động trong game có thể chấp nhận xác nhận nhanh hơn nhưng yếu hơn.

Một khoản thanh toán tài chính lớn có thể cần tính cuối cùng mạnh hơn.

Người dùng nên hiểu không phải mọi xác nhận đều như nhau.

Tower BFT là logic đồng thuận tạo ý nghĩa cho cam kết sâu hơn.

Tower BFT và hiệu suất mạng

Thiết kế Solana hướng đến hiệu suất cao và Tower BFT là một phần của kiến trúc đó.

Bằng cách dùng Proof of History làm nguồn thời gian, Tower BFT có thể giảm một phần chi phí truyền thông điệp trong các thiết kế kiểu BFT cũ.

Ít chi phí hơn có thể giúp mạng ra quyết định nhanh hơn khi điều kiện thuận lợi.

Tuy nhiên, hiệu suất không chỉ phụ thuộc vào đồng thuận.

Nó còn phụ thuộc vào truyền block, thực thi giao dịch, phần cứng validator, kết nối mạng, lưu trữ, thị trường phí và nhu cầu ứng dụng.

Tower BFT hoạt động cùng các thành phần Solana khác xử lý việc tạo block, truyền dữ liệu, thực thi và lưu trữ sổ cái.

Nút thắt ở một phần của hệ thống vẫn có thể ảnh hưởng đến trải nghiệm người dùng.

Đây là lý do hiệu suất blockchain nên được hiểu là vấn đề full-stack.

Tower BFT giúp đồng thuận di chuyển nhanh, nhưng không phải lý do duy nhất mạng có thể xử lý giao dịch.

Nó là một thành phần cốt lõi trong kiến trúc hiệu suất cao lớn hơn.

Tower BFT và chi phí rollback

Chi phí rollback là chi phí hoặc mức độ khó của việc đảo ngược block đã được chấp nhận trước đó.

Tài liệu Anza Tower BFT cho biết chi phí rollback cần có thể tính toán và nên tăng siêu tuyến tính đối với các phiếu bầu cũ hơn.

Khái niệm này quan trọng vì người dùng và ứng dụng cần mức độ tin cậy có thể đo lường đối với thanh toán.

Block vừa được tạo có thể dễ thay thế hơn block bị chôn dưới nhiều phiếu bầu lockout.

Tower BFT làm các cam kết cũ mạnh hơn thông qua lockout xếp chồng.

Điều này nghĩa là đảo ngược lịch sử cũ hơn sẽ cần nhiều validator hơn phá vỡ cam kết mạnh hơn hoặc chờ qua lockout dài hơn.

Trong hệ thống Proof of Stake, hậu quả kinh tế có thể khiến hành vi đó tốn kém.

Chi phí rollback không giống số lượng block đơn giản.

Nó phụ thuộc vào phiếu bầu validator, trọng số stake, độ sâu lockout và quy tắc giao thức.

Hiểu chi phí rollback giúp giải thích vì sao tính cuối cùng tăng theo thời gian.

Tower BFT và các giả định bảo mật

Tower BFT phụ thuộc vào một số giả định bảo mật.

Nó giả định đủ validator theo trọng số stake tuân thủ giao thức một cách trung thực.

Nó giả định validator có thể giao tiếp đủ tốt để mạng tiếp tục tiến triển.

Nó giả định vi phạm lockout có thể được phát hiện và xử phạt theo thiết kế giao thức và quản trị.

Nó giả định thời gian Proof of History có thể xác minh và hữu ích cho việc phối hợp hành vi validator.

Nó cũng phụ thuộc vào việc phần mềm client được triển khai chính xác.

Không có cơ chế đồng thuận nào là phép màu.

Mọi thiết kế đều đánh đổi giữa tốc độ, tính an toàn, tính sống động, phi tập trung, độ phức tạp và rủi ro triển khai.

Tower BFT được thiết kế cho các mục tiêu hiệu suất ban đầu của Solana.

Điểm mạnh và điểm yếu của nó nên được đánh giá trong bối cảnh kiến trúc Solana, thay vì như một hệ thống BFT chung.

Tower BFT và Alpenglow

Alpenglow là thay đổi lớn được đề xuất đối với thiết kế đồng thuận của Solana, có liên quan khi thảo luận về Tower BFT hiện nay.

Đề xuất chính thức SIMD-0326 Alpenglow cho biết đề xuất này thay đổi giao thức đồng thuận cốt lõi từ thiết kế hiện tại dựa trên Proof of History và TowerBFT sang Alpenglow.

Đề xuất này cũng cho biết Alpenglow hướng đến khả năng chống chịu cao hơn và hiệu suất tốt hơn.

Đề xuất cũng nêu giao thức đồng thuận TowerBFT hiện tại có thời gian tính cuối cùng là 12.8 giây và không có chứng minh bảo mật, điều mà đề xuất mô tả là đáng lo ngại.

Điều này không có nghĩa người dùng nên hiểu sai rằng Tower BFT không còn liên quan.

Tower BFT vẫn quan trọng vì nó giải thích kiến trúc đồng thuận ban đầu của Solana và thiết kế mà Alpenglow được dự định thay thế.

Hiểu Tower BFT giúp người dùng hiểu vì sao Alpenglow quan trọng.

Nó cũng giúp nhà phát triển, validator và nhà nghiên cứu so sánh mô hình bỏ phiếu-lockout cũ với các thiết kế mới hơn dựa trên phiếu bầu trực tiếp và chứng chỉ.

Để chính xác trong thuật ngữ, Tower BFT nên được mô tả với nhận thức rằng lộ trình đồng thuận của Solana đang phát triển.

Người dùng luôn nên kiểm tra tài liệu Solana và Anza hiện hành về trạng thái mainnet đang hoạt động của bất kỳ nâng cấp đồng thuận nào.

Ưu điểm của Tower BFT

Ưu điểm đầu tiên của Tower BFT là sử dụng Proof of History làm tham chiếu thời gian chung.

Điều này có thể giảm chi phí giao tiếp so với các thiết kế BFT phải phối hợp timeout qua nhiều lần trao đổi thông điệp hơn.

Ưu điểm thứ hai là lockout khiến phiếu bầu validator có ý nghĩa.

Validator bỏ phiếu cho fork sẽ nhận một cam kết dựa trên thời gian.

Ưu điểm thứ ba là lockout xếp chồng cung cấp cách đánh giá chi phí rollback.

Các block cũ hơn với cam kết sâu hơn trở nên khó đảo ngược hơn.

Ưu điểm thứ tư là Tower BFT phù hợp với kiến trúc thông lượng cao của Solana.

Nó được thiết kế để hỗ trợ xác nhận block nhanh và phối hợp validator.

Ưu điểm thứ năm là biểu quyết theo trọng số stake kết nối ảnh hưởng đồng thuận với stake được ủy quyền.

Điều này trao cho lớp kinh tế vai trò trực tiếp trong lựa chọn fork.

Hạn chế của Tower BFT

Hạn chế đầu tiên của Tower BFT là độ phức tạp.

Proof of History, slot, phiếu bầu, lockout, root và lựa chọn fork có thể khó hiểu đối với người dùng và nhà phát triển.

Hạn chế thứ hai là tính cuối cùng không tức thì.

Cam kết mạnh lên theo thời gian khi phiếu bầu và lockout xếp chồng.

Hạn chế thứ ba là thiết kế gắn chặt với kiến trúc Proof of History của Solana.

Điều này khiến nó ít mang tính tổng quát hơn một số giao thức đồng thuận được thiết kế dựa trên các giả định khác.

Hạn chế thứ tư là chất lượng đồng thuận phụ thuộc vào hiệu suất validator và phân bổ stake.

Kết nối yếu, thời gian ngừng hoạt động hoặc stake tập trung có thể ảnh hưởng đến hành vi mạng.

Hạn chế thứ năm là đề xuất Alpenglow của Solana xác định các lo ngại về hiệu suất và chứng minh bảo mật trong thiết kế TowerBFT cũ.

Các hạn chế này giải thích vì sao nghiên cứu đồng thuận và nâng cấp giao thức vẫn là chủ đề tích cực trong hệ sinh thái Solana.

Những hiểu lầm phổ biến về Tower BFT

Hiểu lầm đầu tiên là cho rằng Tower BFT và Proof of History là một.

Proof of History là cơ chế thời gian và sắp xếp thứ tự, trong khi Tower BFT là cơ chế đồng thuận phiếu bầu-lockout.

Hiểu lầm thứ hai là cho rằng Tower BFT giống Proof of Stake.

Proof of Stake cung cấp ảnh hưởng kinh tế theo trọng số stake, còn Tower BFT tổ chức phiếu bầu và lockout.

Hiểu lầm thứ ba là cho rằng xử lý nhanh luôn đồng nghĩa thanh toán cuối cùng.

Giao dịch có thể được nhìn thấy sớm trong khi tính cuối cùng mạnh hơn phát triển sau đó.

Hiểu lầm thứ tư là cho rằng validator có thể tự do đổi fork.

Lockout Tower BFT hạn chế validator bỏ phiếu cho các fork mâu thuẫn trong thời gian cam kết.

Hiểu lầm thứ năm là cho rằng người dùng phải hiểu mọi chi tiết Tower BFT để sử dụng Solana.

Hầu hết người dùng chỉ cần hiểu cam kết mạnh hơn nghĩa là mức độ tin cậy cao hơn.

Thực hành tốt nhất cho người dùng

Sử dụng ví và ứng dụng đáng tin cậy, hiển thị rõ trạng thái giao dịch.

Chờ cam kết mạnh hơn khi chuyển tài sản giá trị cao.

Không cho rằng giao dịch hiển thị nhanh đồng nghĩa đã đạt tính cuối cùng mạnh nhất có thể.

Khi cần, hãy kiểm tra trạng thái giao dịch qua trình khám phá blockchain hoặc giao diện ứng dụng đáng tin cậy.

Hiểu rằng tắc nghẽn mạng, hiệu suất validator và lỗi ứng dụng vẫn có thể ảnh hưởng đến trải nghiệm người dùng.

Tránh gửi giao dịch lặp lại khi chưa kiểm tra giao dịch đầu tiên đã được xử lý hay chưa.

Sử dụng biện pháp kiểm soát trượt giá khi tương tác với giao thức DeFi.

Giữ đủ SOL để trả phí giao dịch khi sử dụng ứng dụng dựa trên Solana.

Không xem tốc độ đồng thuận là bảo đảm lợi nhuận giao dịch.

Sử dụng nhận thức về tính cuối cùng như một phần của quản lý rủi ro crypto rộng hơn.

Thực hành tốt nhất cho nhà phát triển

Chọn mức cam kết dựa trên rủi ro và giá trị của hành động trong ứng dụng.

Không xem mọi giao dịch được quan sát là có mức tính cuối cùng như nhau.

Thiết kế giao diện người dùng giải thích rõ trạng thái chờ xử lý, đã xác nhận và đã hoàn tất.

Xử lý cẩn thận việc thử lại giao dịch để tránh hành động người dùng trùng lặp hoặc mâu thuẫn.

Theo dõi hành vi liên quan đến fork và tính nhất quán RPC khi xây dựng ứng dụng giá trị cao.

Sử dụng nhà cung cấp hạ tầng đáng tin cậy và nhiều nguồn dữ liệu khi phù hợp.

Thiết kế ứng dụng DeFi có xét đến trượt giá, thay đổi trạng thái và thời điểm xác nhận.

Kiểm thử hành vi ứng dụng trong điều kiện tắc nghẽn và xác nhận chậm.

Cập nhật các nâng cấp đồng thuận Solana, bao gồm thay đổi liên quan đến Alpenglow.

Các giả định đồng thuận nên là một phần của kỹ thuật ứng dụng, không phải điều được cân nhắc sau cùng.

FAQ

Tower BFT là gì, theo cách đơn giản?

Tower BFT là hệ thống bỏ phiếu validator kiểu BFT ban đầu của Solana, sử dụng thời gian Proof of History để giúp validator thống nhất về chuỗi chính xác.

Tower BFT có giống Proof of History không?

Không. Proof of History cung cấp cấu trúc thời gian và sắp xếp thứ tự có thể xác minh, còn Tower BFT dùng cấu trúc đó cho phiếu bầu và lockout validator.

Tower BFT có giống Proof of Stake không?

Không. Proof of Stake cung cấp lớp kinh tế theo trọng số stake, còn Tower BFT cung cấp logic bỏ phiếu và lựa chọn fork.

Vì sao gọi là Tower BFT?

Nó được gọi là Tower BFT vì phiếu bầu validator xếp chồng với lockout tăng dần, tạo cấu trúc cam kết giống một tòa tháp.

Lockout trong Tower BFT là gì?

Lockout là khoảng thời gian dựa trên slot mà validator không thể bỏ phiếu cho fork mâu thuẫn nếu không vi phạm cam kết trước đó.

Slot trong Tower BFT là gì?

Slot là đơn vị thời gian của Solana dành cho lịch leader, tạo block, bỏ phiếu và đo lường lockout.

Validator có vai trò gì trong Tower BFT?

Validator phát lại sổ cái, đánh giá block, bỏ phiếu cho fork và giúp cluster chọn chuỗi hợp lệ nặng nhất thông qua phiếu bầu theo trọng số stake.

Tower BFT làm gì khi có fork?

Tower BFT giúp validator đánh giá các fork cạnh tranh và cam kết với một fork qua phiếu bầu theo trọng số stake và lockout.

Tower BFT có mang lại tính cuối cùng tức thì không?

Không. Tính cuối cùng mạnh lên theo thời gian khi phiếu bầu xếp chồng và lockout sâu hơn.

Vì sao Proof of History hỗ trợ Tower BFT?

Proof of History cung cấp tham chiếu thời gian chung, giúp Tower BFT thực thi timeout và lockout với chi phí truyền thông điệp thấp hơn.

Chi phí rollback trong Tower BFT là gì?

Chi phí rollback là độ khó hoặc chi phí kinh tế của việc đảo ngược block sau khi validator xây dựng cam kết lockout phía trên block đó.

Người dùng có thể tương tác trực tiếp với Tower BFT không?

Không. Hầu hết người dùng tương tác qua ví và ứng dụng, còn validator xử lý việc bỏ phiếu Tower BFT ở phía sau.

Vì sao người dùng DeFi nên quan tâm đến Tower BFT?

Người dùng DeFi nên quan tâm vì đồng thuận ảnh hưởng đến thứ tự giao dịch, độ mạnh xác nhận, mức độ tin cậy thanh toán và độ tin cậy ứng dụng.

Alpenglow liên quan thế nào đến Tower BFT?

Alpenglow là thiết kế lại đồng thuận Solana được đề xuất, sẽ thay thế giao thức hiện tại dựa trên Proof of History và TowerBFT bằng kiến trúc mới hơn.

Tower BFT vẫn đáng tìm hiểu không?

Có. Tower BFT quan trọng vì giải thích kiến trúc đồng thuận ban đầu của Solana và nền tảng để so sánh các đề xuất đồng thuận mới hơn.

Kết luận

Tower BFT là cơ chế bỏ phiếu Khả năng chịu lỗi Byzantine của Solana được tối ưu hóa cho Proof of History.

Nó sử dụng slot, phiếu bầu validator, lockout, root và lựa chọn fork theo trọng số stake để giúp mạng hội tụ về một lịch sử sổ cái chung.

Proof of History cung cấp cấu trúc thời gian chung, Proof of Stake cung cấp trọng số bỏ phiếu kinh tế và Tower BFT cung cấp logic đồng thuận phiếu bầu-lockout.

Ý tưởng chính của Tower BFT là phiếu bầu validator nên tạo các cam kết dựa trên thời gian, mạnh lên khi có thêm phiếu bầu hậu duệ.

Cam kết xếp chồng này khiến block cũ khó rollback hơn và mang lại cho người dùng sự tin cậy lớn hơn khi giao dịch nhận cam kết mạnh hơn.

Tower BFT quan trọng với người dùng, nhà phát triển, validator, trader, giao thức DeFi và ứng dụng NFT vì đồng thuận ảnh hưởng đến thanh toán, thứ tự, tính cuối cùng và độ tin cậy.

Điểm mạnh gồm phối hợp nhanh, thời gian dựa trên PoH, biểu quyết theo trọng số stake và chi phí rollback có thể tính toán.

Hạn chế gồm độ phức tạp, tính cuối cùng không tức thì, phụ thuộc vào hành vi validator và các lo ngại được nêu trong đề xuất đồng thuận mới hơn như Alpenglow.

Khi lộ trình đồng thuận Solana phát triển, Tower BFT vẫn là thuật ngữ thiết yếu để hiểu cách Solana ban đầu kết hợp Proof of History với bỏ phiếu validator kiểu BFT.

Trong thuật ngữ crypto, Tower BFT nên được hiểu là cơ chế đồng thuận Solana biến phiếu bầu validator thành các cam kết xếp chồng dựa trên thời gian nhằm lựa chọn fork và củng cố tính cuối cùng.