Hiểu cơ chế đồng thuận và 11 thuật toán đồng thuận chính thống trong một bài viết

Cơ chế đồng thuận tốt nhất luôn là cơ chế phù hợp với nhu cầu của người dùng.

Diễn giả: Uchiha Madara

** CHỈNH SỬA: Puffs**

Nguồn:Deschool

Bài viết này là ghi chú nghiên cứu của bài học thứ ba trong khóa học đại học web3 của DeSchool, và giảng viên là Uchiha Madara. Nội dung quá khô và không hòa lẫn với nước, bạn nên thu thập và tiêu hóa từ từ. Ngoài ra, để tiện cho việc tìm hiểu, bài viết này có một số sửa đổi, bổ sung cho phù hợp với nội dung môn học.

Nội dung chính của bài viết bao gồm:

  1. Giới thiệu về thuật toán đồng thuận

  2. Phân loại thuật toán đồng thuận

  3. Giải thích chi tiết các thuật toán đồng thuận (PoW, PoS, PoH, PoA, PBFT, v.v.)

01 Giới thiệu về Cơ chế Đồng thuận

Trong giao tiếp và học tập về chuỗi khối, "thuật toán đồng thuận" là một từ vựng được nhắc đến rất thường xuyên, chính vì sự tồn tại của thuật toán đồng thuận mà độ tin cậy của chuỗi khối mới có thể được đảm bảo.

**1. Tại sao chúng ta cần một cơ chế đồng thuận? **

Cái gọi là sự đồng thuận có nghĩa là nhiều người đạt được thỏa thuận. Cuộc sống của chúng ta đầy rẫy những cơ chế đồng thuận, chẳng hạn một công ty cần các cổ đông thảo luận tập thể để đưa ra quyết định, bên A và bên B cần ngồi lại đàm phán để ký kết hợp đồng. Quá trình này là quá trình đạt được sự đồng thuận.

Trong hệ thống chuỗi khối, điều mà mỗi nút phải làm là làm cho sổ cái của nó thống nhất với sổ cái của các nút khác. Nếu nó ở trong một kịch bản tập trung truyền thống, thì đây hầu như không phải là vấn đề, bởi vì có một máy chủ trung tâm, được gọi là thư viện chính và các thư viện phụ khác có thể được liên kết với thư viện chính.

Nhưng trong phân cấp quản lý thì không có ông chủ, vậy phải ra quyết định như thế nào? Lúc này cần một bộ thuật toán để đảm bảo sự đồng thuận. Đây là những gì bài viết này sẽ nói về - cơ chế đồng thuận.

**2. Cơ chế đồng thuận là gì? **

Cơ chế đồng thuận (Cơ chế đồng thuận) hoàn thành việc xác minh và xác nhận các giao dịch trong một khoảng thời gian rất ngắn thông qua việc bỏ phiếu của các nút đặc biệt; đối với một giao dịch, nếu một số nút có lợi ích không liên quan có thể đạt được sự đồng thuận, chúng ta có thể coi rằng toàn bộ mạng Cũng có sự đồng thuận về điều này.

Mặc dù tính đồng thuận (Consensus) và tính nhất quán (Consistency) được coi là tương đương nhau trong nhiều tình huống ứng dụng, nhưng có những khác biệt tinh tế trong ý nghĩa của chúng: Nghiên cứu về sự đồng thuận tập trung vào quy trình và thuật toán của các nút phân tán đạt được sự đồng thuận, trong khi nghiên cứu về tính nhất quán tập trung vào kết quả cuối cùng. trạng thái ổn định của quy trình đồng thuận nút; ngoài ra, hầu hết các nghiên cứu đồng thuận phân tán truyền thống không xem xét vấn đề chịu lỗi Byzantine, tức là giả định rằng không có nút Byzantine nào giả mạo hoặc giả mạo dữ liệu một cách ác ý. Rốt cuộc, trong một mạng blockchain hoàn toàn mở và minh bạch, không có gì đảm bảo rằng tất cả các nút sẽ không làm điều ác.

**3. Cơ chế đồng thuận có thể giải quyết những vấn đề gì? **

Cơ chế đồng thuận có thể giải quyết vấn đề tin cậy trong hệ thống phân tán và đảm bảo tính nhất quán và bảo mật dữ liệu giữa các nút. Trong một hệ thống phân tán truyền thống, do không có cơ chế tin cậy giữa các nút nên nó dễ bị tấn công và giả mạo bởi các nút độc hại, dẫn đến sự cố hệ thống hoặc giả mạo dữ liệu. Ngoài ra, trước khi công nghệ mã hóa chuỗi khối xuất hiện, tiền kỹ thuật số được mã hóa, giống như các tài sản khác, có khả năng nhân rộng vô tận, nếu không có cơ quan trung gian tập trung, mọi người không có cách nào để xác nhận xem một khoản tiền kỹ thuật số đã được chi tiêu hay chưa.

Nói một cách đơn giản, cơ chế đồng thuận có thể giải quyết hiệu quả hai vấn đề: vấn đề chi tiêu gấp đôi (một khoản tiền được chi tiêu hai lần) và vấn đề chung của Byzantine (các nút độc hại can thiệp vào dữ liệu).

4. Tấn công chi tiêu gấp đôi

** **

Cơ chế đồng thuận có thể giải quyết cuộc tấn công chi tiêu gấp đôi ở một mức độ nhất định: tức là một khoản tiền được chi tiêu gấp đôi hoặc nhiều hơn hai lần, còn được gọi là "chi tiêu gấp đôi". Trong trò chơi mèo vờn chuột, Xiao Lizi đã thực hiện hành vi chi tiêu gấp đôi bằng cách làm séc giả, vì việc xác minh séc mất nhiều thời gian nên anh ta đã sử dụng thông tin của cùng một tấm séc để mua hàng nhiều lần trong khoảng thời gian chênh lệch này.

Như chúng ta đã biết, các nút blockchain luôn coi chuỗi dài nhất là chuỗi chính xác và tiếp tục hoạt động cũng như mở rộng chuỗi đó. Nếu hai nút phát các phiên bản khác nhau của một khối mới cùng một lúc, thì công việc sẽ được thực hiện trên cơ sở khối nhận được trước, nhưng chuỗi kia cũng sẽ được giữ lại trong trường hợp chuỗi sau trở thành chuỗi dài nhất. Chờ cho đến khi bằng chứng công việc tiếp theo được tìm thấy và một trong các chuỗi được chứng minh là chuỗi dài hơn, sau đó các nút hoạt động trên chuỗi nhánh khác sẽ đổi trại.

** Chi tiêu gấp đôi đạt được như thế nào? Chia thành hai tình huống:**

**(1) Chi tiêu gấp đôi trước khi xác nhận. **Các giao dịch không được xác nhận cuối cùng có thể không được ghi vào chuỗi khối. Trừ khi số tiền nhỏ, tốt nhất là tránh chi tiêu gấp đôi như vậy ít nhất là chờ xác nhận.

**(2) Chi tiêu gấp đôi sau khi xác nhận. **Điều này yêu cầu kiểm soát hơn 50% sức mạnh tính toán để thực hiện. Đó là, tương tự như một ngã ba nhỏ, đưa các giao dịch cho một cửa hàng vào các khối mồ côi. Loại chi tiêu gấp đôi sau khi xác nhận này rất khó thực hiện, nhưng nó chỉ khả thi về mặt lý thuyết.

** Có ba cuộc tấn công chi tiêu gấp đôi phổ biến nhất: tấn công 51%, tấn công chủng tộc và tấn công Finney. **

Tấn công 51%: Tấn công 51% là khi một người hoặc một nhóm giành quyền kiểm soát 51% sức mạnh băm của chuỗi khối, có nghĩa là họ có khả năng kiểm soát một số khía cạnh của dự án. Trên một chuỗi khối bằng chứng công việc như Bitcoin, điều này sẽ đạt được bằng cách giành quyền kiểm soát sức mạnh khai thác của mạng. Mặt khác, đối với một chuỗi khối bằng chứng cổ phần như Cardano, điều này sẽ đạt được bằng cách kiểm soát 51% số mã thông báo được đặt cọc.

Race Attack: Người dùng gửi hai giao dịch cho hai người bán (hoặc người bán và người dùng) cùng một lúc. Do đó, kẻ tấn công nhận được hai bộ hàng hóa hoặc nhận hàng hóa và thu hồi chi phí giao dịch ban đầu.

Tấn công Finney: Một người khai thác khai thác một khối hoặc một loạt các khối chứa các giao dịch chuyển tiền đến địa chỉ của chính anh ta. Các khối được khai thác không được công bố nhưng được lưu giữ trong khi người khai thác chuyển tiền cho người bán. Sau đó, người bán sẽ giải phóng hàng hóa mà người khai thác đã trả tiền trước khi người khai thác xuất bản khối mà họ đã đào. Sau đó, những người khai thác sẽ xuất bản các khối đã được đào, điều này sẽ xóa chuyển khoản cho người bán và để người bán trả tiền túi cho nó.

Trường hợp tấn công hoa kép kinh điển:

Vào năm 2018, kẻ tấn công đã kiểm soát hơn 51% sức mạnh tính toán trên mạng BTG. Trong thời gian kiểm soát sức mạnh tính toán, hắn đã gửi một lượng BTG nhất định vào ví của mình trên sàn giao dịch. Nhánh này được đặt tên là nhánh A. Đồng thời, gửi các BTG này đến một ví khác do chính bạn kiểm soát và chi nhánh này được đặt tên là chi nhánh B. Sau khi giao dịch trên nhánh A được xác nhận, kẻ tấn công ngay lập tức bán BTG để lấy tiền mặt. Sau đó, kẻ tấn công khai thác trên nhánh B. Vì nó kiểm soát hơn 51% sức mạnh tính toán nên chiều dài của nhánh B sẽ sớm vượt quá chiều dài của nhánh A và nhánh B sẽ trở thành chuỗi chính. rollback để khôi phục trạng thái trước đó. BTG mà kẻ tấn công đã đổi lấy tiền mặt trước đó đã trở lại tay của chính anh ta và những BTG này là tổn thất của cuộc trao đổi. Bằng cách này, kẻ tấn công, dựa vào hơn 50% khả năng kiểm soát sức mạnh tính toán, đã nhận ra "chi tiêu gấp đôi" của cùng một loại tiền điện tử.

5. Thất bại Byzantine

** **

Bài toán các tướng lĩnh Byzantine là một bài toán giả định do Leslie Lamport đặt ra vào những năm 1980. Byzantium là thủ đô của Đế chế Đông La Mã, do lãnh thổ của Đế chế La Mã Byzantine lúc bấy giờ rộng lớn nên nơi đóng quân của mỗi đội quân cách xa nhau, các tướng lĩnh chỉ có thể đưa tin bằng sứ giả. Trong trường hợp xảy ra chiến tranh, các tướng lĩnh phải xây dựng một kế hoạch hành động thống nhất.

Tuy nhiên, có những kẻ phản bội trong số những vị tướng này, những kẻ hy vọng sẽ phá hoại kế hoạch hành động nhất quán của các tướng lĩnh trung thành bằng cách tác động đến việc xây dựng và phổ biến kế hoạch hành động thống nhất. Vì vậy, các tướng phải có một hiệp định phương pháp định sẵn, để tất cả các tướng trung thành có thể đồng ý. Và một số ít những kẻ phản bội không thể làm cho các tướng trung thành thực hiện kế hoạch sai lầm. Nói cách khác, bản chất của vấn đề các tướng lĩnh Byzantine là tìm cách khiến các tướng lĩnh thiết lập sự đồng thuận về kế hoạch chiến đấu trong một môi trường không tin tưởng với những kẻ phản bội.

Trong các hệ thống phân tán, đặc biệt là trong môi trường mạng blockchain, nó cũng tương tự như môi trường chung của Byzantine, có máy chủ bình thường (tương tự như tướng quân Byzantine trung thành), có máy chủ bị lỗi và máy chủ phá hoại (tương tự như tướng quân Byzantine phản bội). Cốt lõi của thuật toán đồng thuận là hình thành sự đồng thuận về trạng thái của mạng giữa các nút bình thường. Nếu chỉ có 3 nút thì bài toán tướng Byzantine không thể giải được. Khi có x nút bài toán trong các nút và tổng điểm nhỏ hơn 3x+1 thì bài toán tướng Byzantine không có lời giải.

Sự xuất hiện của Bitcoin đã giải quyết dễ dàng vấn đề này, nó làm tăng thêm chi phí truyền thông tin, giảm tốc độ truyền thông tin và thêm yếu tố ngẫu nhiên để chỉ một tổng thể có thể phát thông tin trong một khoảng thời gian nhất định. Tướng đầu tiên phát tin nhắn là máy tính đầu tiên tìm thấy hàm băm hợp lệ và miễn là các tướng khác nhận và xác minh hàm băm hợp lệ này cũng như thông tin đính kèm, họ chỉ có thể cập nhật chúng bằng bản sao thông tin mới của sổ cái, và sau đó tính toán lại giá trị băm. Vị tướng tiếp theo tính toán giá trị băm hiệu quả có thể đính kèm thông tin cập nhật của mình với giá trị băm hiệu quả và phát cho mọi người. Sau đó, cuộc đua tính toán hàm băm sẽ bắt đầu lại từ một điểm xuất phát mới. Do thông tin mạng được đồng bộ hóa liên tục, tất cả các máy tính trên mạng sử dụng cùng một phiên bản sổ cái.

02 Phân loại thuật toán đồng thuận

1. Lịch sử của Cơ chế Đồng thuận

Khi máy tính và mạng trở nên phổ biến vào những năm 1980 và 1990, cơ sở dữ liệu dùng chung đã xuất hiện để nhiều người dùng có thể truy cập thông tin mà họ lưu trữ. Hầu hết đều có cơ sở dữ liệu trung tâm mà người dùng có thể truy cập từ các trang khác nhau. Thiết lập này phát triển thành một mạng tập trung nơi quản trị viên cấp quyền cho người dùng và duy trì tính toàn vẹn của dữ liệu.

Các cơ sở dữ liệu dùng chung này được gọi là sổ cái phân tán vì chúng ghi lại thông tin và được nối mạng để nhiều người dùng ở các địa điểm khác nhau truy cập. Một trong những vấn đề quan trọng nhất cần được giải quyết là ngăn chặn giả mạo dữ liệu và truy cập trái phép, độc hại hay không. Cần có một cách để tự động hóa việc quản lý cơ sở dữ liệu phân tán để đảm bảo dữ liệu không bị thay đổi.

Nhu cầu này đã dẫn đến việc tạo ra sự đồng thuận tự trị phân tán, trong đó các chương trình trên mạng sử dụng mật mã để đồng ý về trạng thái của cơ sở dữ liệu. Giao thức được thiết kế để đạt được bằng cách sử dụng thuật toán mật mã để tạo một chuỗi dài các số chữ và số (băm), sau đó được xác minh bởi một chương trình chạy trên mạng. Hàm băm chỉ thay đổi khi thông tin được đưa vào thuật toán băm thay đổi, vì vậy các chương trình được thiết kế để so sánh các hàm băm để đảm bảo chúng khớp với nhau.

Khi mọi chương trình chạy trên mạng đã tạo ra một chuỗi băm phù hợp, dữ liệu được cho là đã đạt được sự đồng thuận trên toàn mạng. Do đó, một cơ chế đồng thuận đã được thiết lập, thường ghi công cho người tạo Bitcoin ẩn danh Satoshi Nakamoto. Tuy nhiên, nhiều người đã làm việc trên cơ chế đồng thuận trong nhiều năm trước khi Satoshi phát hành sách trắng khiến Bitcoin trở nên nổi tiếng.

Các nhà khoa học máy tính và dữ liệu như Moni Naor, Cynthia Dwork, Adam Beck, Nick Szabo và nhiều người khác đã nghiên cứu và đóng góp vào sự phát triển của các cơ chế đồng thuận của mạng.

2 Phân loại thuật toán đồng thuận

Theo các loại khả năng chịu lỗi khác nhau, thuật toán đồng thuận có thể được chia thành hai loại: thuật toán đồng thuận CFT (khả năng chịu lỗi không phải của Byzantine, nghĩa là các nút độc hại không được xem xét) và thuật toán đồng thuận BFT (khả năng chịu lỗi của Byzantine, nghĩa là là, các nút độc hại được xem xét) .

Việc chấp nhận Byzantium có đánh dấu liệu thuật toán có thể được áp dụng cho các mạng có độ tin cậy thấp hay không. Nói chung, thuật toán chịu lỗi Byzantine phải được sử dụng trong môi trường chuỗi công khai, trong khi trong chuỗi liên minh, nó có thể được lựa chọn theo mức độ tin tưởng giữa những người tham gia liên minh. Nếu mức độ tin cậy cao, mọi người là một nút trung thực theo mặc định và có thể sử dụng thuật toán CFT (không chịu lỗi của Byzantine).

**Ngoài ra, nó có thể được chia thành hai loại theo tính nhất quán: **thuật toán đồng thuận xác suất và thuật toán nhất quán tuyệt đối. Thuật toán đồng thuận xác suất có nghĩa là giữa các nút phân tán khác nhau, có xác suất cao để đảm bảo rằng dữ liệu giữa các nút là nhất quán, nhưng vẫn có một xác suất nhất định là dữ liệu giữa một số nút không nhất quán. Ví dụ: Proof of Work (PoW), Proof of Stake (PoS) và Proof of Stake được ủy quyền (DPoS) đều là các thuật toán đồng thuận xác suất.

Thuật toán nhất quán tuyệt đối có nghĩa là tại bất kỳ thời điểm nào, dữ liệu giữa các nút phân tán khác nhau sẽ vẫn hoàn toàn nhất quán và sẽ không có sự không nhất quán dữ liệu giữa các nút khác nhau. Ví dụ, thuật toán PAXOS và thuật toán RAFT dẫn xuất của nó.

Sau đây là sự phân chia và giới thiệu cụ thể theo loại khả năng chịu lỗi.

Thuật toán đồng thuận 3CFT

Crash Fault Tolerance non-Byzantine error: phù hợp với các mạng có mức độ tin cậy nút cao. Bao gồm cả Paxos, Raft.

Thuật toán đồng thuận 4BFT

Kiểm tra xem nút có lỗi Byzantine độc hại hay không có xu hướng cấu trúc phi tập trung, bao gồm bằng chứng công việc (PoW), bằng chứng cổ phần (PoS), bằng chứng cổ phần được ủy quyền (DPoS), bằng chứng về quyền hạn (PoA), v.v.

03 Giải thích chi tiết thuật toán đồng thuận

Xem cái này có hơi mệt không, bấm yêu thích, nghỉ ngơi và tiếp tục gặm nhấm phần khó nhất của bài viết này! Sinh viên có thời gian hạn chế có thể bắt đầu trực tiếp từ thuật toán PoW thứ ba.

Thuật toán 1Paxos

** **

  • **Giới thiệu thuật toán: **Năm 1990, thuật toán Paxos là thuật toán đồng thuận phân tán dựa trên việc truyền thông điệp do Lamport đề xuất và đã giành được Giải thưởng Turing năm 2013. Kể từ khi Paxos ra đời, nó đã tiếp tục độc quyền thuật toán đồng thuận phân tán, chủ yếu giải quyết cách đạt được sự đồng thuận về một giá trị cụ thể trong một hệ thống phân tán. Quy trình đồng thuận của thuật toán Paxos là Người đề xuất đưa ra một đề xuất để giành được sự ủng hộ của hầu hết Người chấp nhận. Khi một đề xuất nhận được hơn một nửa số ủng hộ, kết quả cuối cùng sẽ được gửi tới tất cả các nút để xác nhận. Trong quá trình này, nếu Người đề xuất thất bại, nó có thể được giải quyết bằng cách kích hoạt cơ chế hết thời gian, Nếu Người đề xuất của mỗi vòng đề xuất mới không thành công, hệ thống sẽ không bao giờ có thể đạt được sự đồng thuận. Nhưng xác suất của điều này là vô cùng nhỏ.

Giao thức Basic Paxos ban đầu rất phức tạp và tương đối kém hiệu quả, vì vậy một phiên bản cải tiến của Paxos đã được đề xuất sau đó. Ví dụ: Fast Paxos, Multi-Paxos và Byzanetine Paxos, v.v.

  • **Trường hợp sử dụng: **ZooKeeper
  • **Nguyên tắc của thuật toán: **Thuật toán Paxos chạy trong một hệ thống không đồng bộ cho phép thời gian chết và lỗi, không yêu cầu gửi tin nhắn đáng tin cậy và có thể chịu được tình trạng mất tin nhắn, chậm trễ, rối loạn và lặp lại. Nó sử dụng cơ chế đa số (Majority) để đảm bảo khả năng chịu lỗi 2f+1, nghĩa là một hệ thống có 2f+1 nút cho phép tối đa f nút bị lỗi cùng một lúc. Miễn là có ít hơn (n-1)/2 thất bại, Paxos đạt được sự đồng thuận. Những lỗi này không thể là Byzantine, nếu không bằng chứng BFT sẽ bị vi phạm. Do đó, tiền đề của thuật toán này là giả định rằng các thông báo không bao giờ có thể bị hỏng và các nút đó không thể thông đồng để làm hỏng hệ thống.

Paxos tiến hành thông qua một tập hợp các vòng đàm phán trong đó một nút có trạng thái "lãnh đạo". Nếu người lãnh đạo không trực tuyến, tiến độ sẽ bị đình trệ cho đến khi người lãnh đạo mới được bầu hoặc nếu người lãnh đạo cũ đột ngột trực tuyến trở lại.

Paxos phân chia các vai trò trong hệ thống thành người đề xuất (Proposer), người ra quyết định (Acceptor) và người học quyết định cuối cùng (Learner): Người đề xuất: đưa ra đề xuất (Proposal). Thông tin đề xuất bao gồm số đề xuất (Proposal ID) và giá trị đề xuất (Value). Người chấp nhận: Tham gia vào việc ra quyết định và phản hồi các đề xuất của Người đề xuất. Sau khi nhận được Đề xuất, đề xuất có thể được chấp nhận. Nếu Đề xuất được chấp nhận bởi đa số Người chấp nhận, thì Đề xuất được cho là đã được phê duyệt. Người học: Không tham gia vào việc ra quyết định, tìm hiểu đề xuất (Giá trị) mới nhất được thống nhất từ Người đề xuất/Người chấp nhận.

2. Thuật toán bè

**Giới thiệu về thuật toán:**Thuật toán Raft (Replication and Fault Tolerant) là một triển khai đơn giản hóa của cặp thuật toán Paxos. bè tạo ra nhiều đơn giản hóa tốt đẹp so với Paxos với việc tiếp tục nhật ký. Nó đảm bảo tính nhất quán của hệ thống khi hơn một nửa số nút trong một hệ thống gồm n nút đang hoạt động bình thường. Không giống như thuật toán Paxos, bắt nguồn trực tiếp từ vấn đề nhất quán phân tán, thuật toán Raft được đề xuất từ góc độ của máy trạng thái nhiều bản sao và được sử dụng để quản lý sao chép nhật ký của máy trạng thái nhiều bản sao. Ví dụ: trong hệ thống 5 nút, 2 nút được phép có lỗi không phải lỗi Byzantine, chẳng hạn như thời gian ngừng hoạt động của nút, phân vùng mạng và độ trễ tin nhắn.

**Trường hợp sử dụng: **Sao chép chính-phụ cơ sở dữ liệu, chuỗi liên minh.

Nguyên tắc thuật toán: Có ba vai trò trong hệ thống Raft: Người lãnh đạo, Người theo dõi và Ứng viên. Trong các trường hợp bình thường, sẽ chỉ có một người lãnh đạo và những người khác là người theo dõi. Và người lãnh đạo sẽ chịu trách nhiệm về tất cả các yêu cầu bên ngoài, nếu máy của người lãnh đạo không nhận được, yêu cầu sẽ được chuyển đến người lãnh đạo. Thường thì leader sẽ gửi tin nhắn vào một thời điểm cố định, tức là theo nhịp tim (heartbeat), để những người theo dõi biết rằng leader của cụm vẫn đang hoạt động. Mỗi người theo dõi sẽ thiết kế một cơ chế hết thời gian chờ (timeout), khi không nhận được nhịp tim trong một khoảng thời gian nhất định (thường là 150 ms hoặc 300 ms) thì hệ thống sẽ vào trạng thái bầu cử.

Lúc này cụm bước vào vòng bầu cử (nhiệm kỳ) mới và bắt đầu bầu cử, nếu bầu chọn thành công thì cụm trưởng mới bắt đầu thực hiện công việc, nếu không nhiệm kỳ coi như kết thúc và bắt đầu nhiệm kỳ mới và cuộc bầu cử tiếp theo sẽ bắt đầu.

Các cuộc bầu cử được điều hành bởi các ứng cử viên. Điều này yêu cầu các ứng cử viên tự đề cử và thu hút phiếu bầu từ các máy chủ khác trên cơ sở ai đến trước được phục vụ trước khi nhịp tim của người lãnh đạo ngừng đập. Mỗi máy chủ chỉ bỏ một phiếu bầu cho mỗi vòng bầu cử cho hoặc chống lại ứng cử viên hiện tại. Nếu bạn không nhận được quá nửa số phiếu bầu, bạn sẽ đi đến vòng bầu cử tiếp theo. Các ứng cử viên còn lại tiếp tục tự đề cử trên cơ sở ai đến trước được phục vụ trước. cho đến khi một nhà lãnh đạo được bầu chọn.

**Ưu điểm của thuật toán Raft: **Điểm đầu tiên là tính đơn giản. Nếu chúng ta đào sâu tìm hiểu xem Paxos phức tạp hơn Raft ở chỗ nào, Heidi Howard và Richard Mortier nhận thấy rằng sự phức tạp của Paxos thể hiện ở hai khía cạnh. Đầu tiên, Raft cam kết các bản ghi một cách tuần tự, trong khi Paxos cho phép các bản ghi được cam kết không theo thứ tự, nhưng yêu cầu một giao thức bổ sung để lấp đầy các lỗ hổng nhật ký có thể phát sinh do đó. Thứ hai, tất cả các bản sao của nhật ký trong Raft đều có cùng chỉ mục, thuật ngữ và thứ tự, trong khi ở Paxos, các thuật ngữ này có thể khác nhau.

Điểm thứ hai là Raft có thuật toán bầu chọn thủ lĩnh hiệu quả. Thuật toán bầu cử được đưa ra trong bài báo Paxos so sánh kích thước của id máy chủ. Khi một số nút tham gia bầu cử cùng một lúc, nút có id máy chủ lớn hơn sẽ thắng. Vấn đề là nếu thủ lĩnh được bầu theo cách này thiếu một số nhật ký, nó không thể ngay lập tức thực hiện thao tác ghi và trước tiên phải sao chép một số nhật ký từ các nút khác. Nhật ký Raft luôn có thể chọn nút có nhật ký đa số, do đó không cần phải theo kịp nhật ký. Mặc dù đôi khi cuộc bầu cử sẽ được thử lại do phân chia phiếu bầu, nhưng nói chung đây là thuật toán bầu cử hiệu quả hơn.

Đối với thuật toán Paxos, nếu một máy chủ chậm hơn rất nhiều, thậm chí chậm hơn vài ngày trong nhật ký, nhưng được bầu làm người dẫn đầu tại một thời điểm nào đó, điều này sẽ gây ra một khoảng thời gian nhất định để chặn. Trong thuật toán Raft, một nút có nhật ký ở phía sau sẽ không bao giờ được chọn.

3 Bằng chứng về Công việc (PoW)

Giới thiệu thuật toán: Một công nghệ máy tính lần đầu tiên được sử dụng để chống thư rác. Vào năm 2008, Satoshi Nakamoto đã đề xuất Bitcoin và chuỗi khối trong sách trắng Bitcoin "Bitcoin: Hệ thống tiền mặt điện tử ngang hàng" và thiết kế một cách sáng tạo thuật toán PoW, được áp dụng cho Bitcoin để giải một câu đố toán học để tham gia vào sự đồng thuận. Nội dung cốt lõi của thuật toán là sử dụng sức mạnh tính toán để tìm ra giá trị nonce thỏa mãn hàm băm khối. Tuy nhiên, mọi người nhanh chóng phát hiện ra các vấn đề của cơ chế đồng thuận này, đó là mức tiêu thụ năng lượng lớn và việc kiểm soát sức mạnh tính toán của các nhóm khai thác lớn vẫn sẽ dẫn đến các vấn đề tập trung.

**Các trường hợp sử dụng:**Bitcoin, ETH1.0, Litecoin, Conflux, Dogecoin.

Nguyên tắc thuật toán: Đặc điểm chính của hệ thống bằng chứng công việc là khách hàng cần thực hiện một số công việc khó khăn để nhận được kết quả, nhưng người xác minh có thể dễ dàng kiểm tra xem khách hàng đã thực hiện công việc tương ứng hay chưa thông qua kết quả . Một tính năng cốt lõi của sơ đồ này là tính bất đối xứng: công việc vừa phải đối với người yêu cầu và dễ dàng xác minh đối với người xác minh. Nó khác với hình ảnh xác thực, được thiết kế để con người dễ giải quyết hơn là máy tính.

Proof of Work (PoW) tìm thấy một Nonce số thông qua tính toán, sao cho giá trị băm của nội dung sau khi dữ liệu giao dịch được ghép lại với nhau đáp ứng giới hạn trên được chỉ định. Sau khi nút tìm thấy thành công giá trị băm thỏa mãn, nó sẽ phát khối được đóng gói tới toàn bộ mạng ngay lập tức và các nút của mạng sẽ xác minh ngay sau khi nhận được khối được đóng gói được phát.

Nhược điểm: Tốc độ chậm; tiêu tốn năng lượng lớn, không tốt cho môi trường; dễ bị ảnh hưởng bởi "quy mô kinh tế".

Ưu điểm: Được thử nghiệm rộng rãi từ năm 2009 và vẫn được sử dụng rộng rãi cho đến ngày nay.

4 Bằng chứng cổ phần (PoS)

Giới thiệu thuật toán: Năm 2011, Quantum được đề xuất trên diễn đàn Bitcointalk. Vào tháng 8 năm 2012, Peercoin, dự án blockchain đầu tiên dựa trên sự đồng thuận của PoS, đã ra đời và là ứng dụng đầu tiên triển khai thuật toán PoS. Mối quan tâm đối với Peercoin là tuổi đồng xu, là sản phẩm của số lượng đồng xu được nắm giữ bởi nút và thời gian nắm giữ. Bắt đầu một giao dịch sẽ tiêu tốn một lượng tuổi đồng xu nhất định và mỗi lần tiêu thụ 365 đồng xu tuổi, một năm sẽ thu được lãi suất 5%.

Người dùng: Ethereum(2.0), Conflux, Peercoin.

Nguyên tắc thuật toán: Ví dụ: nếu ai đó giữ 100 Dotcoin trong một giao dịch trong tổng cộng 30 ngày, thì tuổi tiền tệ là 3000. Sau đó, một khối PoS được tìm thấy, tuổi tiền tệ được xóa thành 0 và tiền lãi thu được Nó là 0,05*3000/365=0,41 xu. Trong quá trình đồng thuận, các nút có được quyền ghi sổ thông qua tuổi xu đã tiêu thụ. Nút tiêu thụ tuổi xu càng nhiều thì cơ hội có được quyền ghi sổ càng lớn. Nguyên tắc của chuỗi chính do thuật toán đặt ra là: chuỗi tiêu thụ nhiều tiền tệ nhất là chuỗi chính xác và hiệu quả trong hệ thống.

Ưu điểm: Không cần thiết bị khai thác mạnh mẽ, đắt tiền. Giảm mức tiêu thụ tài nguyên và giảm khả năng bị tấn công 51%.

Nhược điểm: Nó có thể khiến người giàu tích trữ tiền điện tử, tạo thành hiệu ứng Matthew, có thể gây ra lạm phát tiền điện tử.

5 Bằng chứng lịch sử (PoH)

**Giới thiệu về thuật toán: **Bằng chứng về lịch sử được tạo bởi Solana, một chuỗi khối thông lượng cao được ra mắt vào năm 2018. Bằng chứng về lịch sử cho phép những người tham gia mạng đạt được sự đồng thuận đúng hạn bằng cách sử dụng chức năng trì hoãn có thể kiểm chứng, do đó tránh được "thời gian dài nhất quy tắc dây chuyền".

PoH là đồng hồ của mạng và TowerBFT là tháp canh của nó, có nhiệm vụ ngăn chặn các nút độc hại giả mạo các tham số thời gian. Bất kỳ người xác thực nào đã bỏ phiếu cho một khối phải đợi khối tiếp theo được tạo ra và nhận được xác nhận từ bằng chứng lịch sử rằng "thời gian đã trôi qua" trước khi bỏ phiếu lại.

Solana khéo léo tách chuỗi thời gian và trạng thái dựa trên hàm băm.Thay vì liên kết các hàm băm của mỗi khối lại với nhau, trình xác minh trong mạng tự băm hàm băm trong khối.Cơ chế này là PoH. PoH thiết lập một chuỗi các sự kiện có thể xác minh bằng mật mã theo thời gian bằng cách sử dụng Hàm độ trễ có thể xác minh tần số cao (VDF). Về cơ bản, điều này có nghĩa là PoH giống như một chiếc đồng hồ mật mã giúp mạng thống nhất về thời gian và thứ tự của các sự kiện mà không cần chờ thông báo từ các nút khác. Đầu ra tuần tự của các hàm băm trạng thái chuỗi khối đã được chứng minh trong lịch sử đưa ra một chuỗi các sự kiện có thể kiểm chứng được.

**Người dùng:**Solana

Nguyên tắc thuật toán: Nhà lãnh đạo tạo dấu thời gian cho từng dữ liệu chữ ký (giao dịch cần chứng minh) và trực tiếp sắp xếp giao dịch, do đó tránh được vấn đề sắp xếp thời gian trong PoS và mỗi người xác minh bảo đảm có thể xác minh độc lập, giúp rút ngắn đáng kể vấn đề sắp xếp lại thời gian trong quá trình xác minh và chỉ cần xác minh bằng chứng giao dịch.

Ưu điểm: Phí thấp, chỉ một phần trăm cho mỗi giao dịch, tốc độ giao dịch nhanh, khả năng mở rộng tốt,

**Nhược điểm: **Mối lo ngại về tính tập trung, Solana hiện có ít hơn 1200 trình xác thực xác thực giao dịch trên mạng của mình. Ít ứng dụng phi tập trung hơn: Thường được gọi là sát thủ Ethereum. Theo trang web của mình, hơn 350 Dapp đã được tạo trên Solana, so với gần 3.000 trên Ethereum và đây là lúc Defi hiện cần thêm thời gian phát triển và đổi mới.

6 Bằng chứng về quyền hạn (PoA)

Giới thiệu thuật toán: Nó được đề xuất vào năm 2017 bởi Gavin Wood, người đồng sáng lập Ethereum (ETH) và Parity Technologies. Cơ chế PoA không khai thác và không yêu cầu Mã thông báo. Trong mạng chuỗi khối dựa trên PoA thứ cấp, tất cả các giao dịch và khối được xử lý bởi trình xác thực. Chi phí bảo trì của nền tảng PoA thấp, nhưng trong PoA, người xác minh chuỗi khối xác minh và giao dịch phải là người có thể vượt qua đánh giá độ tin cậy. Do đó, người xác minh PoA phải hết sức chú ý đến danh tiếng của chính họ. Danh tiếng là một tài sản rất quan trọng trong PoA. Thông thường, người xác nhận tiết lộ danh tính thực tế của họ. Hiện tại, công nghệ chuỗi khối được hình thành bởi cơ chế đồng thuận này chủ yếu được áp dụng cho các chuỗi liên minh và chuỗi riêng với các đặc điểm ngành rõ ràng.

Người dùng: PoA, Ethereum Kovantestnet, xDai, VeChain và chuỗi hậu cần của Walmart.

Nguyên tắc thuật toán:

a.Chọn đơn vị chứng nhận có thẩm quyền;

b. Một số người xác minh sẽ tạo ra các khối để ghi lại các giao dịch và nhận phần thưởng khối cũng như phí giao dịch. Trong PoA, người xác minh là chìa khóa cho toàn bộ cơ chế đồng thuận Người xác minh có quyền đảm bảo mạng bằng cách đặt danh tính này để đổi lấy phần thưởng khối. Nếu người xác minh hành động ác ý hoặc thông đồng với những người xác minh khác trong suốt quá trình, các tác nhân độc hại có thể bị xóa và thay thế thông qua quản lý trên chuỗi. Các biện pháp bảo vệ chống gian lận hợp pháp hiện có được áp dụng trên toàn mạng để bảo vệ người tham gia khỏi các hành động nguy hiểm của người xác thực.

lợi thế:

A. Yêu cầu sức mạnh tính toán ít hơn, không khai thác, tiết kiệm năng lượng và bảo vệ môi trường;

b Xác minh nhanh chóng và hỗ trợ giao dịch nhanh hơn;

c. Những người xác minh của toàn bộ mạng giám sát lẫn nhau và họ có thể bỏ phiếu để tham gia những người xác minh có kinh nghiệm hoặc loại bỏ những người xác minh không đủ tiêu chuẩn bất cứ lúc nào

d. Các hard fork được pháp luật bảo vệ và mỗi Người xác thực đều ký một thỏa thuận pháp lý.

sự thiếu sót:

a. Nhận dạng công khai, quyền riêng tư và ẩn danh sẽ giảm

b. Trình xác nhận được chỉ định là các nút có thẩm quyền tập trung được hỗ trợ hợp pháp

**7 Bằng chứng công việc bị trì hoãn (**Bằng chứng công việc bị trì hoãn, dPoW)

** **

**Giới thiệu thuật toán:**Trước khi giải thích DPoW, bạn cần giải thích PoB là gì. PoB (Proof of Burn) được gọi là cơ chế đốt bằng chứng, là cam kết bầu chọn người có quyền lãnh đạo mạng bằng cách đốt các mã thông báo trong tay của chính mình. Số lượng mã thông báo bị đốt cháy càng nhiều thì khả năng đạt được vị trí dẫn đầu mạng càng cao.

Trong chuỗi khối dựa trên dPoW, những người khai thác không còn được thưởng mã thông báo để khai thác, mà là "gỗ" có thể đốt được - đốt gỗ. Những người khai thác sử dụng sức mạnh tính toán của riêng họ để cuối cùng chứng minh khối lượng công việc của họ thông qua thuật toán băm, sau đó thu được loại gỗ tương ứng, không thể giao dịch được. Khi gỗ đã tích lũy đến một số lượng nhất định, bạn có thể đến địa điểm đốt để đốt gỗ.

Sau khi tính toán bằng một bộ thuật toán, người đốt nhiều gỗ hơn hoặc BP hoặc một nhóm BP có thể có quyền tạo khối trong phân đoạn sự kiện tiếp theo và nhận phần thưởng (Mã thông báo) sau khi tạo khối thành công. Vì có thể có nhiều người đốt củi trong một khoảng thời gian nên xác suất tạo khối trong khoảng thời gian tiếp theo được xác định bởi lượng củi do chính người đó đốt. Đốt càng nhiều, xác suất giành được quyền sản xuất khối trong khoảng thời gian tiếp theo càng cao.

Điều này có thể đạt được sự cân bằng giữa sức mạnh tính toán và quyền khai thác. Công cụ khai thác và nhóm khai thác có sức mạnh tính toán khổng lồ không nhất thiết phải trở thành nhà sản xuất khối. Những người khai thác nhỏ cũng có một mùa xuân, miễn là họ làm việc chăm chỉ và tích lũy một lượng gỗ nhất định, họ cũng có thể tạo ra các khối. Hiệu quả được đảm bảo, mọi người đều tham gia và cách tham gia phổ biến nhất đảm bảo khái niệm phân cấp, ngăn chặn các tổ chức có sức mạnh tính toán hoặc chủ sở hữu tiền tệ lớn thống trị mạng.

**Người dùng:**Komodo

Nguyên tắc thuật toán: Có hai loại nút trong hệ thống dPoW: nút công chứng và nút bình thường. 64 nút công chứng được bầu chọn bởi các bên liên quan của chuỗi khối dPoW để thêm các khối được công chứng từ chuỗi khối dPoW vào chuỗi khối PoW đính kèm. Khi một khối được thêm vào, hàm băm của khối đó sẽ được thêm vào giao dịch Bitcoin được ký bởi 33 nút công chứng và tạo ra một bản ghi khối dPow được băm vào chuỗi khối Bitcoin. Hồ sơ đã được công chứng bởi đa số các nút công chứng trong mạng.

Để tránh các cuộc chiến khai thác giữa các nút công chứng và giảm hiệu quả của mạng, Komodo đã thiết kế một phương pháp khai thác bằng cơ chế bỏ phiếu, có hai chế độ hoạt động.

Ở chế độ "Không công chứng", tất cả các nút mạng được hỗ trợ để tham gia khai thác, tương tự như cơ chế đồng thuận PoW truyền thống. Trong chế độ "Công chứng viên đang hoạt động", công chứng viên mạng khai thác bằng cách sử dụng tỷ lệ độ khó của mạng giảm đáng kể. Trong chế độ "kích hoạt công chứng", mỗi công chứng viên được phép sử dụng độ khó hiện tại của mình để khai thác một khối, trong khi các nút công chứng khác phải sử dụng độ khó khai thác gấp 10 lần và tất cả các nút bình thường sử dụng độ khó gấp 100 lần so với nút công chứng để khai thác.

**Ưu điểm: **Tiết kiệm năng lượng; tăng cường bảo mật; có thể tăng thêm giá trị cho các chuỗi khối khác bằng cách gián tiếp cung cấp Bitcoin (hoặc bất kỳ chuỗi bảo mật nào khác) mà không phải trả giá giao dịch Bitcoin (hoặc bất kỳ chuỗi bảo mật nào khác).

Nhược điểm: Chỉ các chuỗi khối sử dụng PoW hoặc PoS mới có thể áp dụng thuật toán đồng thuận này; trong chế độ "Hoạt động của Công chứng viên", các hàm băm của các nút khác nhau (các nút công chứng hoặc nút thông thường) phải được hiệu chỉnh tỷ lệ, nếu không thì sự khác biệt giữa các tỷ lệ băm sẽ bùng nổ .

8 PoS được ủy quyền (DPoS, Proof-of-Stake được ủy quyền)

Giới thiệu thuật toán: Cơ chế DPoS, còn được gọi là "Cơ chế bằng chứng ủy quyền chia sẻ" và "Cơ chế ủy thác", được đề xuất vào tháng 4 năm 2014 bởi Dan Larimer (BM), nhà phát triển chính của Bitshares. Ở một góc độ nào đó, DPOS hơi giống hệ thống nghị viện hay hệ thống đại hội nhân dân. Nếu một đại biểu không thực hiện nhiệm vụ của họ (không thể tạo ra một khối khi đến lượt của họ), thì họ sẽ bị hủy niêm yết và mạng sẽ chọn một siêu nút mới để thay thế họ.

Để dễ hiểu, có thể đưa ra một ví dụ khác. Hãy tưởng tượng một công ty có tổng cộng 1.000 nhân viên, mỗi người nắm giữ một lượng cổ phần khác nhau của công ty. Thỉnh thoảng, nhân viên có thể bỏ phiếu cho 10 người mà họ công nhận nhất để lãnh đạo công ty và quyền biểu quyết của mỗi nhân viên tỷ lệ thuận với số cổ phần mà anh ta nắm giữ. Sau khi mọi người bình chọn, 10 người có tỷ lệ bình chọn cao nhất sẽ trở thành lãnh đạo của công ty.

Nếu một nhà lãnh đạo không đủ năng lực hoặc làm điều gì đó gây bất lợi cho công ty, nhân viên có thể thu hồi phiếu bầu cho nhà lãnh đạo, khiến tỷ lệ phiếu bầu của anh ta không thể lọt vào top 10, từ đó từ chức quản lý.

Người dùng: BitShares, Steemit, EOS, Lisk, Ark.

**Ưu điểm: **Tiết kiệm năng lượng; nhanh chóng; trang blog có lưu lượng truy cập cao Steemit sử dụng nó. Thời gian khối của EOS là 0,5 giây.

**Nhược điểm: **Hơi tập trung; những người tham gia có cổ phần cao có thể bỏ phiếu để trở thành người xác thực (đây là một vấn đề trong EOS gần đây).

9 Dung sai lỗi Byzantine thực tế (PBFT)

** **

Giới thiệu thuật toán: Trong thuật toán PBFT, một nút sẽ được coi là nút chính, trong khi các nút khác là nút dự phòng. Tất cả các nút trong hệ thống sẽ giao tiếp với nhau, và mục tiêu cuối cùng là mọi người có thể đạt được sự đồng thuận trên nguyên tắc thiểu số phục tùng đa số.

Quy trình đồng thuận:

a. Máy khách gửi yêu cầu đến nút chính để thực hiện một thao tác

b. Nút chính phát yêu cầu này đến từng nút dự phòng

c.Tất cả các nút thực hiện thao tác và trả về kết quả cho máy khách

d. Khi máy khách nhận được f+1 kết quả giống nhau từ các nút khác nhau, quá trình kết thúc. f đại diện cho giá trị tối đa của các nút nằm có thể.

Được sử dụng bởi: HyperLedgerFabric, Stellar, Ripple, Dispatch

**Ưu điểm: ** Tốc độ cao, khả năng mở rộng.

Nhược điểm: Thường được sử dụng trong các mạng riêng tư và được phép.

10 Dung sai lỗi Byzantine được ủy quyền (dBFT Dung sai lỗi Byzantine được ủy quyền, dBFT)

Giới thiệu thuật toán: Cộng đồng blockchain Trung Quốc NEO (trước đây gọi là Xiaoyi) đã đề xuất một thuật toán chịu lỗi Byzantine cải tiến dBFT. Thuật toán này dựa trên ý tưởng thiết kế PoS trên cơ sở PBFT. Người kế toán, và sau đó là người kế toán tiếp cận một sự đồng thuận thông qua thuật toán chịu lỗi Byzantine. Thuật toán này cải thiện tình trạng thiếu tính nhất quán cuối cùng của PoW và PoS, làm cho chuỗi khối phù hợp với các tình huống tài chính.

Ngoài ra, để giải quyết Vấn đề chung của Byzantine, cơ chế "Dung sai lỗi Byzantine được ủy quyền" là một thuật toán đồng thuận đảm bảo khả năng chịu lỗi được triển khai bên trong chuỗi khối NEO. Trong cơ chế này, có hai bên tham gia, một bên là "nút sổ sách kế toán" để làm sổ sách chuyên nghiệp và bên còn lại là người dùng bình thường trong hệ thống.

Người dùng thông thường bỏ phiếu để xác định các nút kế toán dựa trên tỷ lệ nắm giữ của họ. Khi cần thông qua sự đồng thuận, một người phát ngôn được chọn ngẫu nhiên từ các nút kế toán này để lập kế hoạch, sau đó các nút kế toán khác tuân theo khả năng chịu lỗi của Byzantine thuật toán. Tức là, nguyên tắc thiểu số tuân theo đa số đưa ra tuyên bố. Nếu hơn 66% số nút đồng ý với kế hoạch của người nói, thì đạt được sự đồng thuận, nếu không, người nói được bầu lại và quá trình bỏ phiếu được lặp lại.

Vì tất cả các đại biểu đều có thể xác minh các đề xuất khối, nên rất dễ hiểu liệu dữ liệu do người phát biểu gửi là hợp lệ hay không hợp lệ. Vì vậy, nếu diễn giả không trung thực và gửi đề xuất không hợp lệ tới 2/3 số đại biểu, thì các khối sẽ không khớp và chủ sở hữu nút sẽ không xác thực chúng. Một sự đồng thuận đạt được với hai phần ba phiếu bầu và một diễn giả mới được bầu.

**Người dùng:**Neo

Quy trình đồng thuận:

a. Bất kỳ ai cũng có thể là người đại diện miễn là đáp ứng các yêu cầu. Tất cả chủ sở hữu mã thông báo NEO đều có thể bỏ phiếu, các đại biểu không ẩn danh và cần có 1.000 GAS để trở thành chủ sở hữu nút.

b. Một diễn giả được chọn ngẫu nhiên trong số các đại biểu.

c. Người nói xây dựng một khối mới từ các giao dịch đang chờ xác minh. Sau đó, Diễn giả gửi đề xuất cho các đại diện được bầu. Họ phải theo dõi tất cả các giao dịch và ghi lại chúng trên mạng.

d) Đại biểu tự do chia sẻ, so sánh các kiến nghị nhận được để kiểm tra tính chính xác của số liệu cũng như tính trung thực của các diễn giả. Nếu hơn hai phần ba số đại biểu đạt được sự đồng thuận và xác thực nó, thì khối đó sẽ được thêm vào chuỗi khối.

**Ưu điểm: **Nhanh (mất 15-20 giây để tạo một khối); thông lượng giao dịch lớn, không cần tiêu tốn năng lượng, có thể mở rộng và không cần phân nhánh.

Nhược điểm: Không có ẩn danh và cần phải có danh tính thực để được bầu. Mọi người đang cạnh tranh để trở thành chuỗi gốc. Có thể có nhiều chuỗi gốc.

11. Khả năng chịu lỗi Byzantine thực tế khi quay (RBPFT)

Giới thiệu về thuật toán: Các nguyên tắc của dBft và RPBFT tương tự như PBFT, ngoại trừ việc không phải tất cả các nút đều tham gia vào sự đồng thuận, nhưng các nút được chia thành hai loại:

a. Nút đồng thuận: một nút thực hiện quy trình đồng thuận PBFT và có quyền tạo các khối lần lượt

b.Nút xác minh: không thực hiện quy trình đồng thuận, xác minh xem nút đồng thuận có hợp pháp hay không, xác minh khối, sau vài vòng đồng thuận sẽ chuyển sang nút đồng thuận

Trong khả năng chịu lỗi Byzantine vòng tròn, các nút đồng thuận lần lượt được thay thế bằng các nút xác minh.

**Trường hợp sử dụng:**Fisco-BCOS

**Ưu điểm: **Tốc độ truyền nhanh hơn tin đồn và không có gói tin dư thừa

Chia để trị, băng thông ra của mỗi nút là O(1), khả năng mở rộng mạnh mẽ

Nhược điểm: Nút trung gian là một điểm duy nhất và yêu cầu các chiến lược chịu lỗi bổ sung

12. AptosBFT

** **

Giới thiệu thuật toán: Nó cũng là một thuật toán phái sinh của PBFT. Thuật toán đồng thuận được đặt tên theo Aptos dựa trên HotStuff, dựa trên PBFT. Ưu điểm của mô hình thuật toán này giống như củ hành tây và búp bê Nga, cần được bóc từng lớp từng lớp. Mỗi nút chỉ liên lạc với người lãnh đạo, thay vì gửi tin nhắn cho người lãnh đạo và tất cả các "tướng" khác. Người lãnh đạo phát một tin nhắn (khối được đề xuất) để bỏ phiếu; mỗi nút gửi phiếu bầu của mình cho người lãnh đạo đã thu thập tin nhắn.

Trường hợp sử dụng: Aptos

Cuối cùng, một bản tóm tắt của phần này được đính kèm:

** Ngoài ra, có một số thuật toán đồng thuận không phổ biến. **

Vào năm 2015, Giáo sư David Mazieres, giám đốc khoa học của Stellar.org, đã đề xuất Giao thức Đồng thuận Stellar (SCP). các thuộc tính chính của kiểm soát phi tập trung, độ trễ thấp, độ tin cậy linh hoạt và bảo mật tiệm cận.

Trong cùng năm đó, dự án Sawtooth Lake của Hyperledger đã kết hợp sự đồng thuận của Ripple và SCP và đề xuất thuật toán đồng thuận bỏ phiếu đại biểu để xử lý các tình huống ứng dụng yêu cầu giao dịch cuối cùng ngay lập tức.

Vào năm 2016, người chiến thắng Giải thưởng Turing và giáo sư Sivio Micali của MIT đã đề xuất một thuật toán đồng thuận có khả năng chịu lỗi nhanh của Byzantine có tên là AlgoRand. Thuật toán này sử dụng công nghệ xổ số mật mã để chọn người xác minh và người lãnh đạo quá trình đồng thuận và thông qua BA* The Byzantine Fault được thiết kế của nó Tolerant Protocol đạt được sự đồng thuận về các khối mới. AlgoRand yêu cầu rất ít tính toán và rất ít nhánh, đồng thời được coi là một công nghệ đồng thuận sổ cái phân tán thực sự dân chủ và hiệu quả.

Năm 2017, Đại học Cornell đã đề xuất một thuật toán mới có tên là Sleepy Consensus (đồng thuận đang ngủ), sự đồng thuận này nhằm mục đích thực tế là hầu hết các nút đồng thuận quy mô lớn trong môi trường Internet có thể ngoại tuyến và chỉ một số nút trực tuyến. tham gia vào quá trình đồng thuận. Nghiên cứu này chứng minh rằng thuật toán đồng thuận truyền thống không thể đảm bảo tính bảo mật của sự đồng thuận trong môi trường này.Tuy nhiên, sử dụng thuật toán đồng thuận không hoạt động, miễn là số lượng nút trung thực trực tuyến vượt quá số lượng nút bị lỗi, thì tính bảo mật và độ bền có thể được đảm bảo.

##04 Tóm tắt

Nếu bạn nhảy ra khỏi quan điểm của nhà phát triển và bao gồm nhiều cách suy nghĩ kết hợp chính trị và kinh tế hơn, thì có thể có nhiều thuật toán đồng thuận hơn, chẳng hạn như kết hợp các phương pháp đồng thuận tương tự như khái niệm PPP, không chỉ có thể đạt được bản chất trừng phạt đối với hành vi ác ý các bên, mà còn Nó cũng có thể đạt được mục tiêu tiết kiệm năng lượng tính toán một cách hiệu quả nhất.

Nói tóm lại, cơ chế đồng thuận là cốt lõi của công nghệ chuỗi khối, nó có thể giải quyết vấn đề niềm tin trong hệ thống phân tán, đảm bảo tính nhất quán và bảo mật dữ liệu giữa các nút, đồng thời tránh sự tấn công và giả mạo của các nút độc hại, do đó đảm bảo khối Tính ổn định và độ tin cậy của hệ thống dây chuyền. Đồng thời, cơ chế đồng thuận cũng có thể giải quyết vấn đề "chi tiêu gấp đôi" và cải thiện thông lượng cũng như tốc độ xử lý của hệ thống chuỗi khối. Nhưng các thuật toán đồng thuận khác nhau không tuyệt đối an toàn, hiệu quả và phi tập trung.

Không có thuật toán tốt nhất, chỉ có thuật toán phù hợp với bạn nhất. Việc lựa chọn thuật toán đồng thuận có liên quan nhiều đến kịch bản ứng dụng. **Cơ chế đồng thuận tốt nhất luôn là cơ chế phù hợp với nhu cầu của người dùng. **

Tham khảo:

  1. Cơ chế đồng thuận trong chuỗi khối và tiền điện tử là gì?
  1. Mối đe dọa tấn công hoa kép đối với blockchain
  1. Đọc 11 thuật toán đồng thuận chính trong một bài viết và hiểu cặn kẽ PoS, PoW, dPoW, PBFT và dBFT là cái quái gì?

4Hiểu về chi tiêu gấp đôi và cách ngăn chặn các cuộc tấn công

5Giới thiệu về Ứng dụng của Cơ chế Đồng thuận Byzantine

6AptosBFT: tất cả những gì bạn cần biết về sự đồng thuận BFT trong Aptos

Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
  • Phần thưởng
  • Bình luận
  • Chia sẻ
Bình luận
0/400
Không có bình luận
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate.io
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)