Istanbul Byzantine Fault Tolerance (IBFT) là gì? Tìm hiểu Khả năng chịu lỗi Byzantine Istanbul

Cách Istanbul Byzantine Fault Tolerance (IBFT) cải thiện tính cuối cùng và tăng thông lượng trong mạng Ethereum riêng tư.

Các thuật toán đồng thuận (Consensus algorithms) là một trong những đổi mới cốt lõi của blockchain, nhưng cũng là một trong những điều khó hiểu nhất. Satoshi Nakamoto đã tạo ra một phiên bản Proof of Work (PoW) được triển khai như một phương tiện để bảo mật và xác thực đồng thời các giao dịch Bitcoin.

Cộng đồng blockchain đã xây dựng trên tầm nhìn cốt lõi đó để tạo ra Bằng chứng cổ phần Proof of Stake (PoS), Bằng chứng ủy quyền Proof of Authority (PoA), Khả năng chịu lỗi Byzantine thực tế pBFT (Practical Byzantine Fault Tolerant) và nhiều thứ khác đều được thiết kế để xây dựng sự đồng thuận trong một hệ thống, tạo ra một nguồn chân lý duy nhất làm cho blockchain trở nên có giá trị.

Thuật toán IBFT (Istanbul Byzantine Fault Tolerant hay còn gọi là Khả năng chịu lỗi Byzantine Istanbul) là một cơ chế đồng thuận thay thế cho bằng chứng công việc Proof of Work trong mạng Ethereum.

Giống như các thuật toán khác, Thuật toán IBFT đảm bảo một đơn đặt hàng theo thỏa thuận duy nhất cho các giao dịch trong chuỗi khối và cung cấp các lợi ích bổ sung cho các doanh nghiệp, bao gồm cả tính hoàn thiện thanh toán. IBFT lần đầu tiên được triển khai tại Geth bởi Amis Technologies và ngay sau đó được triển khai tại Quorum.

Trước khi đi vào hoạt động của cơ chế đồng thuận IBFT, điều đáng nói là khi nào và tại sao một người muốn sử dụng IBFT. Trong một blockchain công khai, câu trả lời ngắn gọn là có thể bạn sẽ không. Nhưng khi nói đến chuỗi khối liên hợp hoặc riêng tư, IBFT bắt đầu trông khá hấp dẫn.

Thuật toán PoW nổi tiếng tốn kém cả về phần cứng và điện năng. Chi phí này là có chủ đích, để ngăn bất kỳ ai dễ dàng chiếm lấy mạng và do đó PoW rất thích hợp cho các tình huống có toàn quyền phân quyền, nơi bất kỳ ai (kể cả những kẻ tấn công) đều có thể tham gia.

Tuy nhiên, các nút trong chuỗi liên hợp (consortium chain) / chuỗi riêng tư (private chain) được các doanh nghiệp sử dụng về bản chất được tin cậy hơn so với các mã trong chuỗi công khai. Do đó, cơ chế đồng thuận PoW có thể quá nặng nề và các cơ chế khác có thể cung cấp sự tin tưởng “đủ” để chạy một hệ thống phân tán.

Tương tự như vậy, Bằng chứng cổ phần PoW có thể ít liên quan hơn đối với các doanh nghiệp, bởi vì việc thanh toán cho phí gas Ethereum ít quan trọng hơn trong một mạng lưới được phép. Vì các nút không (nhất thiết) cần duy trì tiền tệ trong mạng, PoS sẽ đưa ra các yêu cầu không liên quan.

Xem xét những sự đánh đổi này, Bằng chứng ủy quyền Proof of Authority (PoA) nổi lên như một giải pháp tốt nhất có thể, sử dụng một hệ thống theo đó các nút trong mạng được phân bổ đặc quyền tạo ra các khối mới cho chuỗi bằng cách sử dụng hệ thống vòng lặp hoặc hệ thống tùy ý khác.

Cơ chế IBFT là một trong nhiều hương vị của PoA và cung cấp các lợi ích sau:

• Khối lượng cuối cùng ngay lập tức. Chỉ có 1 khối được đề xuất ở độ cao chuỗi nhất định. Do đó, chuỗi đơn (single chain) sẽ loại bỏ các khối phân nhánh, không chú ý và rủi ro rằng một giao dịch có thể được “hoàn tác” một lần trên chuỗi sau đó.
• Giảm thời gian giữa các khối. Nỗ lực cần thiết để xây dựng và xác thực các khối được giảm đáng kể (đặc biệt đối với PoW), làm tăng đáng kể thông lượng của chuỗi.
• Tính toàn vẹn dữ liệu cao và khả năng chịu lỗi. IBFT sử dụng một nhóm trình xác nhận để đảm bảo tính toàn vẹn của mỗi khối được đề xuất. Phần lớn (~ 66%) trong số các trình xác thực này được yêu cầu ký vào khối trước khi chèn vào chuỗi, khiến cho việc giả mạo khối trở nên rất khó khăn. ‘Quyền lãnh đạo’ của nhóm cũng thay đổi theo thời gian – đảm bảo một nút bị lỗi không thể gây ảnh hưởng lâu dài đến chuỗi.
• Hoạt động linh hoạt. Nhóm trình xác nhận có thể được sửa đổi kịp thời, đảm bảo nhóm chỉ chứa các nút được tin cậy đầy đủ.

Trong phần còn lại của bài viết này, chúng ta sẽ khám phá những cân nhắc kỹ thuật hơn của Khả năng chịu lỗi Byzantine Istanbul (IBFT), thảo luận về nhiều khái niệm được tìm thấy trong EIP và chúng ta đã học được thông qua nghiên cứu của riêng mình.

Lưu ý: Bạn cũng có thể tìm thấy mã IBFT trong yêu cầu kéo go-ethereum #16385.

Hoạt động của Khả năng chịu lỗi Byzantine Istanbul (iBFT)

Cơ chế đồng thuận IBFT bao gồm các thành phần sau:

• Mô hình đồng thuận nhóm lấy cảm hứng từ PBFT.
• Một quy trình mà các thành viên có thể được thêm vào / xóa khỏi nhóm xác thực.

IBFT yêu cầu Block Header phải được làm lại (một cách tinh vi) để hỗ trợ tất cả các khía cạnh của khả năng.

Mô hình đồng thuận nhóm

Tổng quan

IBFT sử dụng một nhóm các nút xác thực (Validators – Trình xác thực) hoạt động trên mạng Ethereum để xác định xem một khối được đề xuất có phù hợp để bổ sung vào chuỗi hay không.

Một nút của Trình xác thực được chọn tùy ý làm Người đề xuất (Proposer) và chịu trách nhiệm xây dựng một khối ở khoảng thời gian khối và chia sẻ khối đó với nhóm. Nếu phần lớn các Trình xác thực cho rằng khối là hợp lệ, nó sẽ được thêm vào blockchain.

Khi hoàn thành vòng đồng thuận, Người xác thực có thể chọn một Người đề xuất mới sẽ chịu trách nhiệm cung cấp Khối ứng cử viên ở khoảng thời gian khối tiếp theo.

Cơ chế đồng thuận là một máy trạng thái được đồng bộ hóa có trách nhiệm đảm bảo tất cả các Trình xác thực nối cùng một khối vào chuỗi ở cùng độ cao.

Nếu một khối không thể chèn, Người đề xuất sẽ được thay đổi và quá trình bắt đầu lại.

Để đảm bảo chỉ một khối có thể được thêm vào máy trạng thái, IBFT ngăn chặn việc thay đổi khối được đề xuất sau khi đa số người xác thực đã đồng ý với việc chèn nó (nhưng không thực hiện công việc đã nói), quá trình này được gọi là ‘Khóa khối – Block Locking’.

Cơ chế đồng thuận IBFT cung cấp sự ổn định của hệ thống với điều kiện ít hơn 1/3 số nút (node) xác thực đang hoạt động không chính xác (do bị xâm nhập hoặc do mã bị lỗi). Tức là để dung nạp F nút bị lỗi, nhóm xác nhận phải chứa ít nhất 3F + 1 nút (nhiều hơn điều này không làm tăng tính toàn vẹn của hệ thống).

Lưu ý: Ở đây F ngụ ý số lượng nút bị lỗi được hệ thống chấp nhận.

Máy trạng thái (State Machine)

Những trạng thái (State)

• Awaiting Proposal. Trình xác thực đang đợi một khối mới được cung cấp bởi người đề xuất hiện tại. Nếu người xác nhận là người đề xuất cho vòng này, họ chuẩn bị khối được đề xuất và truyền nó trong một thông báo chuẩn bị trước.
• Preparing. Đã nhận được một khối được đề xuất (hợp lệ) và đã thông báo cho trình xác nhận-ngang hàng; hiện đang đợi trình xác nhận-ngang hàng thông báo về việc chấp nhận khối của họ.
• Ready. Đã nhận được sự chấp nhận của trình xác nhận ngang hàng đối với khối và đang chờ chúng ở vị trí tương tự. Ở giai đoạn này, khối được đề xuất đã bị ‘khóa’ và không thể thay thế cho đến khi tiến hành thử chèn.
• Round Change. Vòng đấu đã hết thời gian chờ trước khi đạt được sự đồng thuận hoặc không thể chèn khối. Chờ tất cả người xác nhận đồng ý về số vòng tiếp theo.

Chuyển tiếp (Transitions)

• Awaiting Proposal → Preparing. Khi nhận được một khối mới (thông báo Preprepare) từ người đề xuất (tức là khối hợp lệ trong nội dung của nó, cũng như điểm chèn chuỗi được đề xuất của nó).
• Awaiting Proposal → Round Change. Đề xuất đã nhận không phải là một khối hợp lệ theo một bộ quy tắc nhất định (ví dụ: người đề xuất không hợp lệ, đánh số vòng không chính xác).
• Preparing → Ready. Khi nhận được thông báo 2F + 1 (Chuẩn bị thông báo) từ các trình xác nhận hợp lệ cho biết khối được đề xuất phù hợp để chèn.
• Ready → Awaiting Proposal. Khi nhận được thông báo 2F + 1 (Thông báo cam kết) từ các trình xác thực ngang hàng cho biết họ đã sẵn sàng nối khối vào chuỗi. Khi chuyển đổi, quá trình gắn khối vào chuỗi được thực hiện (thành công).
• Ready → Round Change. Tuy nhiên, theo Đề xuất sẵn sàng-> Đang chờ, việc chèn khối không thành công.
• Round Change → Awaiting Proposal. 2F + 1 trong số những người xác nhận đồng ý về số vòng tiếp theo sẽ được sử dụng.

Lưu ý: Tất cả các chuyển đổi thành “RoundChange” dẫn đến việc Trình xác thực truyền thông báo “RoundChange” đến các trình xác nhận cùng cấp của nó.

Khóa khối (Block Locking)

Khả năng chịu lỗi Byzantine Istanbul (iBFT) yêu cầu không được tạo ra các fork. Để đạt được điều này, khi một khối đã được đa số đồng ý (tức là khi vào trạng thái Ready ‘Sẵn sàng’), nó sẽ trở thành “bị khóa – locked in””.

Điều này có nghĩa là không có khối nào khác sẽ được xem xét để chèn cho đến khi cố gắng thêm khối này vào chuỗi. Do đó, hoặc khối được chèn thành công (khi đã nhận đủ thông báo cam kết, trong vòng này hoặc các vòng tiếp theo), hoặc khối không chèn được, sẽ bị loại bỏ và một khối mới được đề xuất ở chiều cao chuỗi hiện tại.

Thành viên nhóm xác thực

Các thành viên của nhóm xác nhận có thể thay đổi theo thời gian thông qua cơ chế bỏ phiếu (vote). Thành viên có thể được thêm hoặc bớt thông qua đa số (Floor(N/2) + 1) phiếu bầu; mỗi phiếu bầu được ghi lại trong Block Header.

Mỗi nút (node) trong mạng (bao gồm cả các nút không xác thực) chịu trách nhiệm theo dõi việc kiểm phiếu cho từng trình xác thực để xác định các Trình xác thực (Validators) hiện tại và đảm bảo chữ ký trên các khối được khai thác nằm trong nhóm dự kiến.

Với mỗi phiếu bầu được chứa trong Block Header, chỉ Người đề xuất (Proposer) cho một vòng nhất định mới có thể bỏ phiếu. Do đó, điều quan trọng là, nếu các nút được thêm / bớt kịp thời, thì vai trò Người đề xuất phải được cập nhật thường xuyên.

Khi một nút đạt được đa số phiếu bầu, họ ngay lập tức tham gia / rời khỏi nhóm trình xác nhận.

IBFT công nhận Kỷ nguyên biểu quyết (Voting Epoch), xác định thời điểm mà tại đó tất cả các phiếu bầu chưa đạt đa số đều bị loại bỏ, buộc phải bắt đầu lại quá trình kiểm phiếu biểu quyết. Điều này ngụ ý khi kiểm đếm phiếu bầu, Người xác thực chỉ cần bắt đầu ở thời điểm gần đây nhất. Theo mặc định, Voting Epoch diễn ra sau mỗi 30.000 khối.

Các phiếu bầu xác định sự thay đổi trạng thái (nghĩa là các ứng cử viên được bỏ phiếu, người xác nhận được bỏ phiếu), không bỏ phiếu cho một nút nhất định ngụ ý Người xác thực không muốn nút đó thay đổi trạng thái (không cần phải biểu quyết rõ ràng để duy trì hiện trạng).

Trình tái cấu trúc Block Header

Để hỗ trợ IBFT trong Ethereum, một số thay đổi phải được thực hiện đối với Block Header. Những thay đổi này bao gồm:

• beneficiary: xác định nút đang bỏ phiếu.
• nonce: chỉ định bỏ phiếu trực tiếp – AUTH hoặc DROP.
• mixHash: một số ma thuật cố định, xác định khối này đang được xác thực IBFT.
• ommersHash: phải là băm của một tập hợp trống, vì không có khối ommer khi hoạt động trong IBFT.
• timestamp: ít nhất phải bằng dấu thời gian của khối mẹ + khoảng thời gian của khối.
• difficulty: phải được điền bằng 0x0000000000000001.
• extraData: chứa dữ liệu cụ thể của IBFT bao gồm Danh sách địa chỉ trình xác thực, ProposerSeal (xác định người đề xuất), committingSeals (danh sách các trình xác thực đã báo cáo ‘cam kết’ trên khối này).

Vì danh sách các committingSeals cho mỗi trình xác thực là (có thể) khác nhau, điều quan trọng là khối băm không bao gồm thông tin này – tức là mặc dù hai khối có các trường committingSeals khác nhau, chúng đại diện cho cùng một thông tin (tức là các giao dịch, v.v. giống hệt nhau).

Sự kết luận về Khả năng chịu lỗi Byzantine Istanbul (iBFT)

Tóm lại, IBFT là một giải pháp chịu lỗi của Byzantine cung cấp khả năng hoàn thiện giao dịch ngay lập tức, làm giảm cơ sở hạ tầng cần thiết mà PoW yêu cầu.

Mặc dù không bao giờ được sử dụng trên mạng chính Ethereum (với nhiều thành phần tham gia rộng hơn, không xác định), nhưng nó mang lại lợi ích đáng kể khi được sử dụng trên một chuỗi riêng tư nơi nhóm xác thực được tin cậy và chịu trách nhiệm; nó cung cấp một giải pháp lý tưởng cho một chuỗi có nhịp cố định và tốc độ xử lý giao dịch có thể dự đoán được.

Các quy trình được khám phá trong bài viết này đưa ra sự tin tưởng rằng một mạng sử dụng IBFT sẽ chịu được các nút Byzantine và có thể được phục hồi nếu các nút đó được xem là thực hiện quyền kiểm soát trên mạng.

Theo: consensys

Khuyến cáo: Thông tin trên bài viết này chỉ mang tính tham khảo, không có bất kỳ lời khuyên nào về mua bán, đầu tư. Bạn hãy tự nghiên cứu trước khi thực hiện bất kỳ hình thức đầu tư nào.

Nội dung đề xuất