chữ
Dung sai lỗi Byzantine thực tế (PBFT) là một phương pháp thực tế để giải quyết vấn đề tướng Byzantine khi kênh đáng tin cậy. Bài toán các tướng lĩnh Byzantine lần đầu tiên được đề xuất bởi Leslie Lamport và cộng sự trong một bài báo [1] xuất bản năm 1982. Trong bài báo, người ta đã chứng minh rằng khi tổng số tướng lĩnh n lớn hơn 3f và số lượng quân đào tẩu là f hoặc kém hơn, các tướng trung thành có thể đạt được sự đồng thuận về mệnh lệnh, cụ thể là 3f+1<=n, độ phức tạp của thuật toán là O(n^(f+1)). Sau đó, Miguel Castro và Barbara Liskov lần đầu tiên đề xuất thuật toán PBFT trong bài báo [2] xuất bản năm 1999. Số lượng khả năng chịu lỗi của thuật toán cũng thỏa mãn 3f+1<=n và độ phức tạp của thuật toán giảm xuống còn O(n^ 2).
Nếu bạn đã hiểu về thuật toán đồng thuận PBFT, bạn có thể quen thuộc với mối quan hệ giữa tổng số nút n và giới hạn trên của khả năng chịu lỗi f: với tiền đề là có tối đa f nút bị lỗi trong hệ thống, tổng số nút n trong hệ thống phải thỏa mãn n>3f Trong quá trình tiến tới sự đồng thuận, cần phải thu thập một số phiếu bầu nhất định để hoàn tất quá trình chứng nhận. Trong phần này, trước tiên chúng ta sẽ thảo luận về cách có thể bắt nguồn mối quan hệ giữa các giá trị này.
--Cơ Chế Số Đại Biểu--
Trong một hệ thống lưu trữ phân tán với dữ liệu dư thừa, các đối tượng dữ liệu dư thừa sẽ lưu trữ nhiều bản sao giữa các máy khác nhau. Nhưng đồng thời, nhiều bản sao của một đối tượng dữ liệu chỉ có thể được sử dụng để đọc hoặc ghi. Để duy trì tính dự phòng và nhất quán của dữ liệu, cần phải có một cơ chế bỏ phiếu tương ứng để duy trì nó, đó là cơ chế Đại biểu. Là một hệ thống phân tán, blockchain cũng cần cơ chế này để bảo trì cụm.
Để hiểu rõ hơn về cơ chế Số đại biểu, trước tiên chúng ta hãy tìm hiểu một cơ chế biểu quyết tương tự nhưng cực đoan hơn - cơ chế WARO (Write All Read One). Khi sử dụng cơ chế WARO để duy trì một cụm có tổng số nút là n, "phiếu bầu" cho các nút thực hiện thao tác ghi phải là n, trong khi "phiếu bầu" cho thao tác đọc có thể được đặt thành 1. Điều đó có nghĩa là, khi thực hiện thao tác ghi, cần đảm bảo rằng tất cả các nút hoàn thành thao tác ghi thì thao tác đó mới được coi là hoàn thành, nếu không thao tác ghi sẽ thất bại; tương ứng, khi thực hiện thao tác đọc, chỉ trạng thái của một nút cần được đọc, Bạn có thể kiểm tra trạng thái hệ thống. Có thể thấy rằng trong cụm sử dụng cơ chế WARO, việc thực hiện thao tác ghi rất mong manh: chỉ cần một nút không thực hiện thao tác ghi thì thao tác không thể hoàn thành. Tuy nhiên, mặc dù tính mạnh mẽ của các thao tác ghi bị hy sinh, nhưng theo cơ chế WARO, rất dễ dàng thực hiện các thao tác đọc trên cụm.
Cơ chế số đại biểu [3] là một cân nhắc thỏa hiệp cho các thao tác đọc và ghi.Đối với mỗi bản sao của cùng một đối tượng dữ liệu, không quá hai đối tượng truy cập sẽ được đọc và ghi, đồng thời cân nhắc các yêu cầu về kích thước đã đặt cho việc đọc và ghi. Trong một cụm phân tán, mỗi đối tượng sao chép dữ liệu được cấp một phiếu bầu. giả định:
Có V vé trong hệ thống, nghĩa là một đối tượng dữ liệu có V bản dự phòng;
Đối với mỗi thao tác đọc, số phiếu thu được không được ít hơn số phiếu đọc tối thiểu R (đại biểu đọc) mới được đọc thành công;
Đối với mỗi thao tác viết, số phiếu thu được không được ít hơn số phiếu viết tối thiểu W (viết đại biểu) để được viết thành công.
Đối với các nút đồng thuận trong cụm, khi tiến hành thuật toán đồng thuận, các nút tham gia đồng thuận sẽ đồng thời thực hiện thao tác đọc ghi trên cụm. Để cân bằng các yêu cầu của thao tác đọc và ghi trên kích thước của tập hợp, R và W của mỗi nút có cùng kích thước, ký hiệu là Q. Khi có tổng cộng n nút trong cụm và có nhiều nhất f nút lỗi, làm cách nào để tính toán mối quan hệ giữa n, f và Q? Tiếp theo, chúng ta sẽ bắt đầu từ kịch bản CFT đơn giản nhất và dần dần khám phá cách có được mối quan hệ giữa các giá trị số này trong kịch bản BFT.
▲CFT
chữ
CFT (Khả năng chịu lỗi sự cố), có nghĩa là các nút trong hệ thống sẽ chỉ gặp phải hành vi lỗi của sự cố (Sự cố) và không có nút nào sẽ chủ động gửi thông báo lỗi. Khi thảo luận về độ tin cậy của thuật toán đồng thuận, chúng ta thường tập trung vào hai thuộc tính cơ bản của thuật toán: tính sống động và tính an toàn. Khi tính độ lớn của Q cũng có thể xét từ hai góc độ này.
Đối với hoạt động và bảo mật, có một cách trực quan hơn để mô tả:
một cái gì đó cuối cùng sẽ xảy ra [4], một sự kiện cuối cùng sẽ xảy ra
điều gì đó tốt đẹp cuối cùng cũng xảy ra[4], sự kiện này cuối cùng sẽ xảy ra là hợp lý
Từ góc độ hoạt động, cụm của chúng tôi cần có khả năng tiếp tục chạy và sự đồng thuận không thể tiếp tục do lỗi của một số nút. Từ góc độ bảo mật, cụm của chúng tôi có thể tiếp tục đạt được kết quả hợp lý trong quá trình thúc đẩy sự đồng thuận, đối với các hệ thống phân tán, yêu cầu cơ bản nhất cho kết quả "hợp lý" này là trạng thái tổng thể của cụm.
Do đó, trong kịch bản CFT, việc xác định giá trị Q trở nên đơn giản và rõ ràng:<=n-f。
Hoạt động: Vì chúng tôi cần đảm bảo rằng cụm có thể tiếp tục chạy, nên chúng tôi phải đảm bảo khả năng nhận được vé Q trong mọi tình huống, để đọc và ghi dữ liệu cho bộ sưu tập. Vì hầu hết f nút trong cụm sẽ ngừng hoạt động, để đảm bảo có thể nhận được Q vé, kích thước của giá trị này cần phải thỏa mãn: Q
▲BFT
Bảo mật: Vì cần đảm bảo cụm không phân kỳ nên theo yêu cầu cơ bản của cơ chế Số đại biểu cần thỏa mãn hai bất đẳng thức đã nêu ở phần trước và Q được đưa vào tập bất đẳng thức này là cực tiểu đọc set và set ghi nhỏ nhất, lúc này Q thỏa mãn quan hệ bất đẳng thức Q+Q>n và Q>n/2 nên độ lớn của giá trị này cần thỏa mãn: Q>n/2.
BFT (Byzantine Fault Tolerance), có nghĩa là các nút sai trong cụm có thể không chỉ ngừng hoạt động mà còn có các hành vi nguy hiểm, tức là các hành vi Byzantine, chẳng hạn như các nhánh trạng thái hoạt động. Trong trường hợp này, đối với toàn bộ cụm, chỉ có các nút nf ở trạng thái đáng tin cậy và khi chúng tôi thu thập Q phiếu bầu, chỉ có Qf phiếu bầu đến từ các nút đáng tin cậy. Do đó, về mặt bảo mật, trong kịch bản BFT, cần đảm bảo rằng sẽ không có sự khác biệt giữa các nút có trạng thái đáng tin cậy, do đó có hai mối quan hệ sau:<=n-f。
Hoạt động: Vẫn chỉ cần đảm bảo rằng luôn có khả năng nhận được Q vé, do đó, Q
▲Tổng số nút và giới hạn trên của khả năng chịu lỗi
chữ
Đối với tổng số nút n và giới hạn trên của khả năng chịu lỗi f, lời giải thích được đưa ra trong bài viết PBFT [1]: Vì có f nút có thể bị hỏng, chúng tôi cần phản hồi ít nhất khi chúng tôi nhận được tin nhắn nf và để chúng tôi nhận được Tin nhắn từ các nút nf, vì có thể có tối đa f tin nhắn từ các nút Byzantine không đáng tin cậy, nó cần phải thỏa mãn nff>f, vì vậy, n>3f.Nói một cách đơn giản, tác giả của PBFT đã thu được mối quan hệ giữa tổng số nút và giới hạn trên của khả năng chịu lỗi từ góc độ hoạt động và bảo mật của cụm. Trong phần trước, chúng ta cũng đã thu được mối quan hệ giữa n, f và Q dưới góc độ hoạt động và an ninh, cũng có thể sử dụng mối quan hệ giữa n và f ở đây: nhằm đáp ứng yêu cầu của hoạt động và an ninh tại đồng thời Q cần thỏa mãn Hệ thức bất đẳng thức Q<=nf và Q>(n+f)/2 nên suy ra hệ thức bất đẳng thức giữa n và f là (n+f)/2
(Theo cách tương tự, cũng có thể thu được mối quan hệ giữa n và f trong cảnh CFT, n>2f.)
--PBFT và RBFT--
Sau khi hiểu mối quan hệ giữa n, f và Q trong kịch bản BFT, hãy chuyển sang phần giới thiệu PBFT. Trước đó, đề cập sơ qua về máy trạng thái sao chép SMR (State Machine Replication) [5]. Trong mô hình này, đối với các máy trạng thái khác nhau, nếu chúng bắt đầu từ cùng một trạng thái ban đầu và nhập cùng một tập lệnh theo cùng một thứ tự, thì chúng sẽ luôn nhận được cùng một kết quả cuối cùng. Đối với thuật toán đồng thuận, nó chỉ cần đảm bảo rằng "các hướng dẫn giống nhau được nhập theo cùng một thứ tự" để có được cùng một trạng thái trên mỗi máy trạng thái. PBFT là sự đồng thuận về thứ tự thực hiện lệnh.
▲ Đồng thuận hai giai đoạn
chữ
So với khái niệm "ba giai đoạn" phổ biến hơn (chuẩn bị trước, chuẩn bị, cam kết), xem PBFT như một giao thức đồng thuận hai giai đoạn có thể phản ánh tốt hơn mục đích của từng giai đoạn: giai đoạn đề xuất (chuẩn bị trước và chuẩn bị) và cam kết giai đoạn (cam kết). Trong mỗi giai đoạn, mỗi nút cần thu thập phiếu bầu nhất trí từ Q nút trước khi bước vào giai đoạn tiếp theo. Để dễ thảo luận hơn, ở đây chúng ta sẽ thảo luận về kịch bản khi tổng số nút là 3f + 1. Lúc này, số lượng vé đọc và ghi Q là 2f + 1.
1) Giai đoạn đề xuất
Trong giai đoạn này, nút chính gửi chuẩn bị trước để bắt đầu đồng thuận và nút phụ gửi chuẩn bị để xác nhận đề xuất của nút chính. Sau khi nhận được yêu cầu từ máy khách, nút chủ sẽ chủ động phát thông báo chuẩn bị trước cho các nút khác
v là chế độ xem hiện tại
n Số thứ tự yêu cầu được chỉ định bởi nút chính
D(m) là thông báo tóm tắt
m là tin nhắn chính nó
Sau khi nhận được thông báo chuẩn bị trước, nút nô lệ sẽ xác minh tính hợp lệ của thông báo, nếu thông qua xác minh, nút sẽ chuyển sang trạng thái chuẩn bị trước, cho biết rằng yêu cầu đã vượt qua xác minh tính hợp pháp tại nút nô lệ. Nếu không, nút nô lệ sẽ từ chối yêu cầu và kích hoạt quá trình chuyển đổi chế độ xem. Khi nút nô lệ vào trạng thái chuẩn bị trước, nó sẽ phát thông báo chuẩn bị cho các nút khác
i là số nhận dạng nút hiện tại
Sau khi các nút khác nhận được thông báo, nếu yêu cầu đã vào trạng thái chuẩn bị trước tại nút hiện tại và nhận được 2f thông báo chuẩn bị tương ứng (bao gồm cả chính nó) từ các nút khác nhau, thì nó sẽ chuyển sang trạng thái chuẩn bị và giai đoạn đề xuất đã hoàn thành. Tại thời điểm này, 2f+1 nút đồng ý gán số thứ tự n cho thông báo m, nghĩa là cụm đồng thuận đã gán số thứ tự n cho thông báo m.
2) Giai đoạn đệ trình
▲Cơ chế điểm kiểm tra
chữ
Trong quá trình vận hành thuật toán đồng thuận PBFT, một lượng lớn dữ liệu đồng thuận sẽ được tạo ra, vì vậy cần triển khai cơ chế thu gom rác hợp lý để kịp thời dọn sạch dữ liệu đồng thuận dư thừa. Để đạt được mục tiêu này, thuật toán PBFT thiết kế một quy trình điểm kiểm tra để thu gom rác.
Checkpoint là điểm kiểm tra, là quá trình kiểm tra xem cụm đã đi vào trạng thái ổn định hay chưa. Khi kiểm tra, các nút phát thông báo điểm kiểm tra
n là số thứ tự yêu cầu hiện tại
d là thông báo thu được sau khi thực hiện thông báo
tôi đại diện cho nút hiện tại
Sau thông báo điểm kiểm tra, có thể coi cụm hiện tại đã vào điểm kiểm tra ổn định (stable checkpoint) cho số thứ tự n. Tại thời điểm này, dữ liệu đồng thuận trước điểm kiểm tra ổn định sẽ không còn cần thiết nữa và có thể được làm sạch. Tuy nhiên, nếu các trạm kiểm soát được thực thi thường xuyên để thu gom rác sẽ mang lại gánh nặng đáng kể cho hoạt động của hệ thống. Do đó, PBFT thiết kế một khoảng thời gian thực hiện cho quy trình điểm kiểm tra và sau mỗi k yêu cầu được thực thi, nút sẽ chủ động khởi tạo một điểm kiểm tra để có được điểm kiểm tra ổn định mới nhất.
Ngoài ra, PBFT giới thiệu khái niệm về hình mờ cao/thấp để hỗ trợ thu gom rác. Trong quá trình đồng thuận, do chênh lệch hiệu suất giữa các nút, có thể xảy ra trường hợp chênh lệch tốc độ hoạt động giữa các nút quá lớn. Số thứ tự được thực hiện bởi một số nút có thể đi trước các nút khác, dẫn đến dữ liệu đồng thuận của các nút hàng đầu không bị xóa trong một thời gian dài, dẫn đến vấn đề sử dụng bộ nhớ quá mức và chức năng của mực nước cao và thấp là để giới hạn tốc độ chạy chung của cụm, do đó Kích thước dữ liệu đồng thuận của các nút bị hạn chế.
▲Xem thay đổi
chữ
Thay đổi chế độ xem được kích hoạt khi nút chính hết thời gian chờ và không phản hồi hoặc khi các nút phụ cùng tin rằng nút chính là nút có vấn đề. Sau khi thay đổi chế độ xem hoàn tất, số chế độ xem sẽ tăng thêm 1 và sau đó nút chính sẽ chuyển sang nút tiếp theo. Như thể hiện trong hình, một ngoại lệ xảy ra trên nút 0 để kích hoạt quá trình thay đổi chế độ xem.Sau khi thay đổi hoàn tất, nút 1 trở thành nút chính mới.
Khi xảy ra thay đổi chế độ xem, nút sẽ chủ động nhập chế độ xem mới v+1 và phát thông báo thay đổi chế độ xem, yêu cầu chuyển đổi nút chính. Tại thời điểm này, cụm đồng thuận cần đảm bảo rằng các yêu cầu đã hoàn thành sự đồng thuận trong chế độ xem cũ có thể được giữ lại trong chế độ xem mới. Do đó, trong yêu cầu thay đổi chế độ xem, thông thường cần phải thêm một phần nhật ký đồng thuận vào chế độ xem cũ và yêu cầu được phát bởi nút là
i là danh tính của nút người gửi
v+1 cho biết chế độ xem mới mà yêu cầu đưa vào
h là chiều cao của điểm kiểm tra ổn định mới nhất của nút hiện tại
Được lưu trữ theo cách tương tự, điều đó có nghĩa là nút hiện tại đã thực hiện kiểm tra điểm kiểm tra với số thứ tự n và thông báo d, đồng thời gửi thông báo đồng thuận tương ứng.
Được lưu trữ theo cách tương tự, điều đó có nghĩa là trong chế độ xem v, yêu cầu có tóm tắt là d và có số thứ tự là n đã vào trạng thái chuẩn bị. Vì yêu cầu đã đạt đến trạng thái chuẩn bị, điều đó có nghĩa là ít nhất 2f+1 nút sở hữu và phê duyệt yêu cầu và việc xác nhận tính nhất quán chỉ có thể được hoàn thành trong giai đoạn cam kết. Do đó, trong chế độ xem mới, phần này của thông báo có thể sử dụng trực tiếp số thứ tự ban đầu mà không gán số thứ tự mới.
cách cất giữ. Vì yêu cầu đã vào trạng thái chuẩn bị trước, điều đó có nghĩa là yêu cầu đã được phê duyệt bởi nút hiện tại.
Tuy nhiên, sau khi nhận được thông báo thay đổi chế độ xem được gửi bởi các nút khác, nút chính P mới tương ứng với chế độ xem v+1 không thể xác nhận liệu thông báo thay đổi chế độ xem có được gửi bởi nút Byzantine hay không và không thể đảm bảo rằng nó phải sử dụng đúng thông báo cho việc ra quyết định. PBFT cho phép tất cả các nút kiểm tra và xác nhận tất cả các thông báo thay đổi chế độ xem mà nó nhận được thông qua thông báo thay đổi chế độ xem và sau đó gửi kết quả đã xác nhận tới P. Nút chính P đếm thông báo xác nhận thay đổi chế độ xem và có thể xác định thay đổi chế độ xem nào là chính xác và thông báo nào được gửi bởi các nút Byzantine.
Khi nút xác nhận thông báo thay đổi chế độ xem, nó sẽ kiểm tra các bộ P và Q trong đó và thông báo yêu cầu trong bộ được yêu cầu phải nhỏ hơn hoặc bằng chế độ xem v. Nếu đáp ứng yêu cầu, thay đổi chế độ xem -ack tin nhắn sẽ được gửi
tôi là ID nút đã gửi tin nhắn xác nhận
j là ID người gửi của thông báo thay đổi chế độ xem sẽ được xác nhận
d là bản tóm tắt của thông báo thay đổi chế độ xem để xác nhận
Khác với việc phát các tin nhắn chung, chữ ký số không còn được sử dụng để xác định người gửi tin nhắn mà khóa phiên được sử dụng để đảm bảo độ tin cậy của giao tiếp giữa nút hiện tại và nút chính, từ đó giúp nút chính để đánh giá độ tin cậy của thông điệp thay đổi lượt xem.
Nút chính mới P duy trì một tập hợp S để lưu trữ thông báo thay đổi chế độ xem chính xác đã được xác minh. Khi P nhận được một thông báo thay đổi chế độ xem và tổng số 2f-1 thông báo thay đổi chế độ xem tương ứng, nó sẽ thêm thông báo thay đổi chế độ xem này vào tập S. Khi kích thước của tập S đạt tới 2f+1, điều đó chứng tỏ rằng có đủ các nút không phải của Byzantine để bắt đầu thay đổi chế độ xem. Nút chính P sẽ tạo một thông báo chế độ xem mới và phát nó theo thông báo thay đổi chế độ xem đã nhận.
Điều đó có nghĩa là bản tóm tắt của thông báo thay đổi chế độ xem được gửi bởi nút i là d, tương ứng với các thông báo trong tập hợp S và các nút khác có thể sử dụng bản tóm tắt và ID nút trong tập hợp để xác nhận tính hợp pháp của thay đổi chế độ xem.
X: Chứa các điểm kiểm tra ổn định và yêu cầu chọn tham gia các chế độ xem mới. Nút chính mới P sẽ tính toán theo thông báo thay đổi chế độ xem của S trong bộ, xác định điểm kiểm tra ổn định tối đa và yêu cầu cần giữ trong chế độ xem mới theo bộ C, P, Q và ghi vào tập X Trong số đó, quy trình lựa chọn cụ thể tương đối rườm rà, độc giả quan tâm có thể tham khảo bài báo gốc [6].
▲Không gian cải tiến và RBFT
RBFT (Robust Byzantine Fault Tolerance) là một thuật toán đồng thuận mạnh mẽ được phát triển bởi Qulian Technology dựa trên PBFT cho nền tảng chuỗi liên minh cấp doanh nghiệp. So với PBFT, chúng tôi đã tối ưu hóa và cải thiện quá trình xử lý thông báo đồng thuận, khôi phục trạng thái nút, bảo trì động cụm và các khía cạnh khác để thuật toán đồng thuận RBFT có thể đối phó với các tình huống thực tế phức tạp và đa dạng hơn.
1) Nhóm giao dịch
Trong quá trình triển khai công nghiệp nhiều thuật toán đồng thuận, bao gồm cả RBFT, một mô-đun nhóm giao dịch độc lập được thiết kế. Sau khi nhận được giao dịch, bản thân giao dịch được lưu trữ trong nhóm giao dịch và giao dịch được chia sẻ thông qua nhóm giao dịch để mỗi nút đồng thuận có thể nhận được giao dịch được chia sẻ. Trong quy trình đồng thuận, chỉ cần đồng thuận với hàm băm giao dịch.
Khi xử lý các giao dịch lớn, nhóm giao dịch có sự cải thiện tốt về tính ổn định của sự đồng thuận. Việc tách riêng nhóm giao dịch khỏi chính thuật toán đồng thuận giúp dễ dàng triển khai nhiều tính năng chức năng hơn thông qua nhóm giao dịch, chẳng hạn như chống trùng lặp giao dịch.
2) Phục hồi tích cực
Trong PBFT, khi một nút nhận thấy rằng mực nước thấp của chính nó ở phía sau điểm kiểm tra hoặc thay đổi chế độ xem, nghĩa là khi điểm kiểm tra ổn định ở phía sau, nút bị trễ sẽ kích hoạt quy trình khôi phục tương ứng để kéo dữ liệu về trước điểm kiểm tra ổn định. Cơ chế khôi phục ngược như vậy có một số nhược điểm: một mặt, quá trình kích hoạt quá trình khôi phục bị động và quá trình khôi phục ngược chỉ có thể được kích hoạt khi quá trình điểm kiểm tra hoặc thay đổi chế độ xem được kích hoạt hoàn tất; mặt khác, đối với nút lùi, nếu điểm kiểm tra Khi phát hiện điểm kiểm tra ổn định của chính nó ở phía sau, nút lùi chỉ có thể khôi phục về điểm kiểm tra ổn định mới nhất chứ không thể nhận được thông báo đồng thuận phía sau điểm kiểm tra và có thể không thực sự tham gia vào đoàn kết.
Trong RBFT, chúng tôi đã thiết kế một cơ chế khôi phục nút hoạt động: một mặt, cơ chế khôi phục có thể được kích hoạt tích cực để giúp các nút bị trễ phục hồi nhanh hơn; mặt khác, trên cơ sở khôi phục về điểm kiểm tra ổn định mới nhất, chúng tôi thiết kế Cơ chế phục hồi giữa các mực nước được thiết lập để các nút bị trễ có thể nhận được tin tức đồng thuận mới nhất và tham gia vào quy trình đồng thuận thông thường nhanh hơn.
3) Bảo trì động cụm
Là một thuật toán đồng thuận được sử dụng rộng rãi trong kỹ thuật, một trong những lợi thế quan trọng của Raft là nó có thể tự động hoàn thành các thay đổi thành viên cụm. Tuy nhiên, PBFT không cung cấp lược đồ thay đổi động cho các thành viên cụm, điều này không đủ trong các ứng dụng thực tế. Trong RBFT, chúng tôi đã thiết kế một sơ đồ để thay đổi linh hoạt các thành viên của cụm sao cho có thể thêm hoặc xóa các thành viên của cụm mà không dừng toàn bộ cụm.
Khi thêm hoặc xóa một nút, quản trị viên sẽ gửi một giao dịch đến cụm để tạo đề xuất vận hành nút và chờ các quản trị viên khác bỏ phiếu. Sau khi bỏ phiếu, quản trị viên đã tạo đề xuất sẽ gửi giao dịch cấu hình đề xuất thực hiện cụm một lần nữa và cụm sẽ được thay đổi trong quá trình cấu hình thực thi.
Đối với phần đồng thuận, khi xử lý và thực hiện giao dịch cấu hình đề xuất, các nút trong cụm sẽ chuyển sang trạng thái thay đổi cấu hình và không có giao dịch nào khác được đóng gói. Nút chính đóng gói giao dịch một cách riêng biệt để tạo gói cấu hình và đồng ý về gói cấu hình. Khi gói cấu hình hoàn thành sự đồng thuận, nó sẽ được thực thi và một khối cấu hình sẽ được tạo. Để đảm bảo rằng khối cấu hình đã sửa đổi không thể được khôi phục, lớp đồng thuận sẽ đợi kết quả thực thi của gói cấu hình đã sửa đổi và xác nhận rằng một điểm kiểm tra ổn định đã được hình thành cho chiều cao của gói cấu hình trong cụm trước khi phát hành trạng thái cấu hình của nút và tiếp tục đóng gói các giao dịch khác.
Phương pháp thay đổi động các thành viên cụm này làm cho việc bảo trì cấu hình cụm trở nên đáng tin cậy và thuận tiện hơn, đồng thời cung cấp khả năng sửa đổi động nhiều thông tin cấu hình hơn.
Giới thiệu về tác giả
Giới thiệu về tác giả
Nhóm Nghiên cứu Thuật toán Đồng thuận của Phòng Nền tảng Cơ bản của Công nghệ FunChain
người giới thiệu
[1] Lamport L, Shostak R, Pease M. The Byzantine generals problem[M]//Concurrency: the Works of Leslie Lamport. 2019: 203-226.
[2] Castro M, Liskov B. Practical Byzantine fault tolerance[C]//OSDI.1999, 99(1999): 173-186.
[3] https://en.wikipedia.org/wiki/Quorum _ (distributed_computing)
[4] Owicki S, Lamport L. Proving liveness properties of concurrent programs[J]. ACM Transactions on Programming Languages and Systems (TOPLAS), 1982, 4(3): 455-495.
[5] Fred B. Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Comput. Surv., 22(4):299–319, 1990.
[6] Castro M, Liskov B. Practical Byzantine fault tolerance andproactive recovery[J]. ACM Transactions on Computer Systems (TOCS), 2002,20(4): 398-461.
IOS
Android