Giao thức đồng thuận Stellar

Trước khi tìm hiểu về giao thức đồng thuận Stellar ta hãy điểm lại sơ sơ về Blockchain 1 tý nhé! Không, nó không phải Proof-Of-Work hay Proof-Of-Stake.

Ghi chú của tác giả ✍️

Bài viết này yêu cầu người đọc phải có một số kiến ​​thức trước đây về sổ cái phân tán.
Ngoài ra, SCP là một khái niệm phức tạp để nắm bắt và bài viết này có nghĩa là một bước giới thiệu để hiểu đầy đủ về giao thức. Đơn giản hóa đã được thực hiện để hạn chế sự phức tạp của văn bản và do đó có thể không đúng về mặt kỹ thuật toàn bộ. Các chứng minh và định lý toán học không được hiển thị vì lý do tương tự.

Sơ lược Blockchain

Nói chung, một Blockchain hoạt động như một sổ cái kỹ thuật số phi tập trung được duy trì thông qua một mạng lưới máy tính phân tán. Trong một hệ thống phân tán, những người tham gia mạng lưới tiền mã hóa cần thường xuyên đạt được sự đồng thuận một cách an toàn và hiệu quả.

Tuy nhiên, việc đạt được sự đồng thuận là khá khó khăn, đặc biệt là khi một số Node có khả năng bị lỗi hoặc hoạt động không trung thực. Nhưng thông qua Hệ thống chịu lỗi Byzantine, một Blockchain có thể tiếp tục hoạt động ngay cả khi một số Node không giao tiếp được.

Byzantine Fault Tolerance – BFT là thuộc tính của hệ thống để chống lại các loại lỗi đến từ các Node không giao tiếp hoặc hoạt động có hại và tiếp tục hoạt động miễn là có đa số các Node đồng ý.

Hệ thống bằng chứng công việc của Bitcoin đã được chứng minh là một trong những cách triển khai BFT an toàn nhất cho Blockchain. Nhưng các câu đố mật mã phức tạp được sử dụng bởi Bitcoin PoW đã khiến mạng khá chậm và không hiệu quả theo quan điểm tiêu thụ năng lượng.

Do đó, nhiều dự án khác đã triển khai các giao thức với BFT có nguồn gốc để tạo ra các mạng cải tiến dựa trên bỏ phiếu, nhanh hơn và rẻ hơn. Tuy nhiên, chúng có một số nhược điểm như rủi ro cao hơn đối với những cú ngã ba vô tình, sự tập trung và sự xuất hiện của những con cá voi mạnh mẽ.

Giới thiệu & khái niệm chính

Trước khi đi sâu vào các kỹ thuật của SCP, có một số thuật ngữ chúng ta nên đề cập:

Mạng Stellar

Stellar là một nền tảng được phát hành vào năm 2014 với mục đích sử dụng Blockchain để cung cấp các dịch vụ tài chính dễ tiếp cận hơn cho mọi người trên toàn thế giới. Nó có IBM, Deloitte và Stripe là đối tác và mã thông báo của nó, được gọi là Lumens – XLM, có vốn hóa thị trường lớn thứ 18 trong tất cả các loại tiền mã hóa tính đến thời điểm này. Mạng Stellar tự hào có các giao dịch rất nhanh với mức phí cực thấp và trong khi trọng tâm của nó là cung cấp nền tảng cho thanh toán xuyên biên giới, nó cũng cho phép tạo ra các hợp đồng thông minh.

Bạn có thể tìm thêm thông tin về Stellar trên trang web của họ www.stellar.org. Hôm nay, chúng ta sẽ chỉ thảo luận về giao thức đồng thuận được sử dụng bởi nền tảng của nó.

Byzantine Generals Problem – BGP

Một đội quân lớn, sau khi đánh bại hầu hết các lực lượng của kẻ thù, bây giờ bao vây thành phố thủ đô, đến từ mọi hướng. Quân đội được chia thành nhiều sư đoàn, và mỗi sư đoàn do một vị tướng điều khiển. Các tướng chỉ liên lạc với nhau thông qua sứ giả. Tất cả đều phải đối mặt với một quyết định: Nên tấn công hay rút lui? Để thành công, họ phải làm việc đó với toàn bộ lực lượng. Trong một kịch bản lý tưởng, các vị tướng sẽ gửi phiếu bầu của họ và đa số phiếu sẽ quyết định kết quả được tuân theo. Tuy nhiên, trên thực tế, có những kẻ phản bội trong quân đội, các thông điệp có thể bị thất lạc hoặc thay đổi trên đường đi, và thông tin liên lạc không phải là tốt nhất ngay cả trong cùng một bộ phận. Ví dụ, một vị tướng có thể gửi một thông điệp cho một người ngang hàng và một thông điệp khác cho một người khác, nếu ông ta là kẻ phản bội. Vì thế, đây là phiên bản đơn giản của BGP.

Các mạng phi tập trung như Blockchains là một vấn đề lớn của Byzantine Generals. Bảo mật của các mạng này phải xuất phát từ một nguyên tắc cơ bản là không phải tất cả những người tham gia trong mạng đều quan tâm đến lợi ích tốt nhất của nó và một số có thể muốn tấn công nó. Làm thế nào chúng ta có thể xây dựng một sổ cái được chấp nhận bởi những người có lẽ là không đáng tin cậy như sự thật và đồng ý về những gì nên được đưa vào sổ cái đó? Để giải quyết vấn đề này, cần có sự đồng thuận, có thể đạt được dưới nhiều hình thức khác nhau, một trong số đó được trình bày trong bài báo này.

Sự đồng thuận trong mạng phân tán

Sự đồng thuận là phán quyết của hầu hết những người có liên quan – Từ điển Merriam-Webster

Khi chúng ta nói về sổ cái, phải có một thỏa thuận rằng thông tin được đăng ký là thực tế. Trong trường hợp sổ cái tập trung truyền thống, thỏa thuận đó rất đơn giản: Quyền lực tập trung, là người duy nhất có quyền truy cập vào sổ cái, chỉ cần tuyên bố thông tin là đúng và điều đó phải được người dùng sổ cái, những người tin tưởng tác nhân tập trung chấp nhận.

Trong trường hợp mạng phân tán, quá trình này phức tạp hơn một chút. Trong Blockchain công khai, bất kỳ ai cũng có thể thêm hoặc cố gắng thêm thông tin vào sổ cái và bất kỳ ai cũng có quyền xác minh xem thông tin đó có đúng hay không. Vì lý do đó, mạng phải đạt được sự đồng thuận, một thỏa thuận chung rằng dữ liệu là chính xác. Tuy nhiên, đó không phải là một nhiệm vụ dễ dàng, bởi vì người dùng và người xác nhận sổ cái là không xác định, và do đó không thể tin cậy được.

Do đó, để đạt được sự đồng thuận giữa các bên không đáng tin cậy và xác nhận tính hợp lệ của dữ liệu được lưu trữ trong sổ cái, phải có một giao thức để xác định các thông tin được thêm vào sổ đăng ký. Đây là lúc các giao thức đồng thuận ra đời. Bitcoin nổi tiếng sử dụng Proof-of-Work để đảm bảo tính hợp lệ của các giao dịch. Cùng với việc yêu cầu sự đồng ý từ số đông, PoW cũng yêu cầu sử dụng tài nguyên, cụ thể là nỗ lực tính toán, để cung cấp thêm bảo mật cho mạng, vì những kẻ tấn công sẽ phải tiêu tốn tài nguyên tiền bạc để cố gắng làm hại mạng. Ngoài ra, những người làm việc ủng hộ mạng được khuyến khích tiếp tục làm như vậy bằng các biện pháp khuyến khích tài chính.

Tuy nhiên, Proof-of-Work có những nhược điểm của nó, dẫn đến việc tạo ra các lựa chọn thay thế nhằm mục đích trở thành một lựa chọn tốt hơn. Proof-of-Stake là một trong những lựa chọn thay thế nổi tiếng nhất cho PoW , một danh mục cũng chứa Giao thức đồng thuận Stellar.

Byzantine Fault Tolerance – BFT

Byzantine Fault Tolerance là chất lượng của một hệ thống chịu được các lỗi cố hữu của BGP. Mạng phân tán có nhiều Node tương tác với nhau để quyết định trạng thái hiện tại của sổ cái. Các Node này có thể là các Node trung thực hoặc chúng có thể bị hỏng và mạng phải có khả năng xử lý tất cả các thông tin sai lệch do các nút bị hỏng phát tán và vẫn đạt được sự đồng thuận về dữ liệu là đúng.
Khi xử lý BFT, không có giới hạn nào được đặt ra liên quan đến hành vi có thể có của một Node. Mạng phải an toàn giả sử các Node có thể hoạt động theo bất kỳ cách nào họ muốn, đây là điều khiến vấn đề rất khó giải quyết. Một mạng Byzantine Fault Tolerant giải quyết vấn đề chi tiêu gấp đôi, như được Satoshi Nakamoto mô tả trong Báo cáo chính thức về Bitcoin .
BFT cực kỳ quan trọng trong lĩnh vực Công nghệ sổ cái phân tán trong đó Blockchain là một phần của nó, nhưng các ứng dụng của nó không chỉ giới hạn ở DLT mà còn được sử dụng, chẳng hạn như trong hệ thống điều khiển của một chiếc Boeing 787.

Giao thức thỏa thuận Byzantine liên bang

Năm 2015, Giáo sư Mazières từ Stanford đã giới thiệu một giải pháp thay thế cho Thỏa thuận Chịu lỗi Byzantine được gọi là Thỏa thuận Byzantine Liên bang. Khái niệm này dựa trên các nhóm Quorum đạt được sự đồng thuận, sử dụng các nhóm Quorum  chồng chéo được hình thành bởi những người xác nhận.

Các giao thức đồng thuận Stellar là giao thức FBA chung đầu tiên đưa ra một hệ thống thành viên mở. Trong hệ thống này, mỗi trình xác nhận sẽ quyết định những trình xác thực nào mà họ tin tưởng để tạo thành một phần Quorum. Do đó, không cần cơ quan trung ương quyết định danh sách người xác nhận.

Trong hệ thống không đồng bộ phân tán, cơ chế đồng thuận phải ưu tiên hai trong ba đặc tính sau:

• Khả năng chịu lỗi: Khả năng của một hệ thống tồn tại sau sự thất bại của trình xác nhận.
• Liveness: Khả năng của hệ thống luôn đóng sổ cái, ngay cả khi nó gây ra một đợt Fork.
• An toàn: Khả năng của một hệ thống để ngăn chặn một lỗi xâm nhập vào sổ cái của nó, cuối cùng ngăn chặn tiến trình của nó.

Phiên bản SCP của Hiệp định Byzantine Liên bang thích khả năng chịu lỗi và an toàn hơn . Ngoài ra, không có quá trình khai thác. Chỉ có một quy trình bỏ phiếu 3-5 giây trong đó các thông điệp được chuyển đi xung quanh để đạt được sự đồng thuận. Và bởi vì ưu tiên an toàn hơn tính sống động, không có rủi ro Fork khiến bạn phải chờ đợi một vài sổ cái, vì vậy một giao dịch là vĩnh viễn ngay từ lần đầu tiên nó đạt được sự đồng thuận.

Liên quan đến bảo mật của mạng, Thỏa thuận Byzantine Liên bang là an toàn tiệm cận vì việc áp dụng sức mạnh tính toán để phá hoại sự đồng thuận là không thể. Và ngay cả khi vẫn có khả năng các tác nhân xấu cấu kết với nhau, thì hầu như không thể để họ tạo thành đa số vì mạng được hình thành từ một mạng phức tạp gồm các lát số đại biểu chồng chéo lên nhau.

Quorums, lát cắt và giao điểm

Về bản chất của SCP là Quorum và đại biểu. Như đã nêu trong Sách trắng SCP, định nghĩa của những khái niệm đó là:

• Quorum: Một tập hợp các Node đủ để đạt được thỏa thuận.
• Quorum Slice: Một tập hợp các Node đủ để thuyết phục một Node khác về tính hợp lệ của một câu lệnh. Còn được gọi là ‘lát cắt đại biểu’.

Các nút trong Mạng Stellar quyết định một cách độc lập những Node nào khác mà họ tin tưởng để cung cấp thông tin. Do đó, tập hợp các Node được chọn là “đáng tin cậy” bởi Node n và chính Node n xác định lát cắt đại biểu của n. Nếu n có l và m trong lát cắt của nó và cả hai đều chấp nhận một phần thông tin nhất định, thì n cũng sẽ chấp nhận thông tin đó. Bây giờ, nếu l và m đều có hai Node khác trong các lát cắt tương ứng của chúng, thì những nút này cũng cần thiết để tạo thành Quorum. Do đó, Quorum là một tập hợp các Node chứa ít nhất một phần từ mỗi thành viên của nó. David Mazières: The Stellar Consensus Protocol Talks at Google.
Hãy hình dung điều này:

Hình 1: Các nhóm Quorum  và các lát cắt Quorum

Đừng lo lắng nếu nó trông hơi phức tạp, hãy chia nó thành nhiều phần.

Quorum 1

Gồm các nút: N1, N2, N3 và N4. Bao gồm các lát:

• N1, N2, N3
• N2, N4
• N3, N4

Quorum 1

Gồm các nút: N5, N6 và N7. Bao gồm các lát:

• N5, N6, N7
• N6, N7

Do đó, chúng tôi có những cân nhắc sau:

N4 có thể xác định sự đồng ý của nhóm Quorum số 1. N7 có thể xác định thỏa thuận của nhóm Quorum số 2. Thỏa thuận của một nhóm Quorum không can thiệp vào thỏa thuận của nhóm kia, vì không có Node nào được chia sẻ giữa chúng. Chúng ta có hai Quorum riêng biệt không giao nhau, còn được gọi là Quorum rời rạc.

Hình 2: Các nhóm Quorum lớn hơn

Ngoài ra, nếu không có N7 và các lát cắt được sắp xếp như trên, chúng ta sẽ không có hai Quorum riêng biệt, mà thay vào đó là một Quorum lớn hơn.

Hình 3: Số lượng giao nhau

Với sự thay đổi hướng trong một số mũi tên của sơ đồ trên, bây giờ chúng ta có thể giới thiệu một khái niệm khác, giao điểm Quorum.

Các giao điểm số đại biểu xảy ra khi hai đại biểu có chung một Node cần thiết để thỏa thuận, do đó can thiệp vào thỏa thuận nội bộ của nhau. Trong hình N1 là giao điểm. N1 là cần thiết để thống nhất trong cả hai Quorum. Một giao thức đồng thuận mạnh cần những điểm giao cắt này, vì nếu không thì mạng có thể đạt được các thỏa thuận riêng biệt. Trên thực tế, mọi Quorum cần ít nhất một giao điểm với nhóm khác để sự đồng thuận hoạt động.

Từ các sơ đồ trên, chúng ta cũng có thể nhận thấy rằng, theo lẽ tự nhiên, nhiều tầng Node khác nhau sẽ hình thành, được xếp theo thứ tự quan trọng đối với sự đồng thuận. Ví dụ trong hình trên, N4 là nút quan trọng nhất của nhóm Quorum, tiếp theo là tầng thứ hai chứa N2 và N3…

Slots

Slots là các bản cập nhật duy nhất cho sổ cái, mà tất cả các Node phải đồng ý. Sách trắng SCP ghi chú:

Ví dụ: Các vị trí có thể là các vị trí được đánh số liên tục trong một nhật ký được áp dụng tuần tự.

Dựa trên định nghĩa ở trên, chúng ta có thể suy ra rằng, trong các Blockchain, các vị trí này trên thực tế là các khối. Tất cả những người tham gia vào mạng lưới Blockchain phải đồng ý về tính hợp lệ của một khối và cập nhật sổ cái cá nhân của họ để bao gồm nó khi nó được xuất bản. Một khi điều đó được thực hiện, sự đồng thuận sẽ đạt được.

Lỗi Node

Bây giờ, chúng ta đã thảo luận về cách sử dụng Quorums, lát cắt và giao điểm để các Node đạt được thỏa thuận. Tuy nhiên, sự đồng thuận trong mạng không thể xảy ra một cách dễ dàng vì các lỗi của Node. Trong một kịch bản lý tưởng, tất cả các Node đều có mục đích tốt và hữu ích cho mạng. Tuy nhiên, như đã nói bởi BFT, để tạo ra một hệ thống thực sự có khả năng chịu lỗi, không có giả định nào có thể được đưa ra về hành vi của các Node, tức là chúng ta phải chuẩn bị cho điều tồi tệ nhất. Hãy xem sơ đồ dưới đây để hiểu các loại lỗi có thể xảy ra với Node.

Hoạt động không tốt

Các Node không hoạt động tốt là những Node không tuân theo các quy tắc giao thức và không hoạt động vì lợi ích tốt nhất của mạng. Họ không chọn các lát cắt Quorum hợp lý, có thể đã bị lỗi, có thể cố tình gửi thông báo sai hoặc có thể đang sửa đổi phần mềm. Các Node này bị lỗi byzantine, do đó, theo mặc định chúng đã bị lỗi. Không phụ thuộc vào ý định của nó, cho dù chúng có độc hại hay không, các Node hoạt động kém không thể được tin cậy để duy trì sự đồng thuận trong mạng.

Hoạt động tốt

Mặt khác, các Node hoạt động tốt là những Node tuân theo giao thức và các phương pháp hay nhất. Họ không chỉ có thiện chí mà còn thực hiện các biện pháp phòng ngừa cần thiết để đảm bảo an toàn và hoạt động bình thường của mạng. Tuy nhiên, chúng vẫn có thể bị hỏng do các yếu tố bên ngoài. Có hai cách mà chúng có thể thất bại, được liệt kê dưới đây:

• Bị chặn: Các nút không thể xuất giá trị cho thỏa thuận mà không dựa vào một Node bị lỗi khác.
• Phân kỳ: Các Node xuất ra một giá trị phân kỳ từ các Node khác cho cùng một đầu vào.
  Đầu vào ở trên đề cập đến một tập hợp dữ liệu mà Node phải cung cấp “câu trả lời”. Tương tự như vậy, nó tương đương với dữ liệu khối, dữ liệu giao dịch, băm khối trước đó, độ khó… mà các thợ đào sử dụng để tìm một hàm băm và giải quyết khối trong Proof of Work. Kết quả đầu ra đề cập đến “câu trả lời” được đưa ra bởi Node liên quan đến tập dữ liệu được xuất bản lên mạng. Tương tự như trên, nó tương đương với hàm băm được tìm thấy bởi người khai thác cho một khối.
• Ví dụ: Giả sử đầu vào là một giao dịch. Đầu ra sau đó phải biểu thị giao dịch đó có hợp lệ hay không. Nếu “ý kiến” của một Node liên quan đến tính hợp lệ của giao dịch dựa trên một Node không hoạt động tốt vì nó là một phần của phần Quorum của nó, nó được coi là bị chặn. Đó là bởi vì đầu ra của nó bị xâm phạm bởi một Node bị lỗi. Nếu một Node, mặc dù hoạt động tốt, xuất ra “hợp lệ”, khi giao dịch trên thực tế không hợp lệ theo sự đồng thuận của mạng, Node đó có thể được coi là khác nhau. Các Node đúng là những Node không bị lỗi theo bất kỳ cách nào.

Bỏ phiếu liên kết – FV

Để đảm bảo sự đồng thuận của mạng vẫn không hề hấn gì bất chấp sự cố của Node, SCP giới thiệu Biểu quyết liên kết – Federated Voting, được sử dụng với Quorums và lát cắt, cho phép một mạng đạt được sự đồng thuận mà không cần tất cả các Node trong mạng. FV có ba giai đoạn:
Bỏ phiếu → Chấp nhận → Xác nhận

Với đầu vào “Có phải là quả cà chua không?”, các Node sẽ bỏ phiếu cho những gì họ cho là hợp lệ. Trong sơ đồ trên, N1 có thể bỏ phiếu “Có” hoặc “Không”. Sau khi được bỏ phiếu, các Node không thể thay đổi phiếu bầu của mình, nhưng chúng có thể chấp nhận một đầu ra khác.

Giả sử N1 phiếu bầu “Không”. N1 sau đó sẽ xem xét túc số của nó. Nếu Quorum bỏ phiếu hoặc chấp nhận “Có”, N1 sau đó sẽ chấp nhận “Có”. Lý tưởng nhất là các hệ thống ảnh hưởng này sẽ thúc đẩy mạng lưới hướng tới sự đồng thuận về đầu ra chính xác.

Các Node nguyên vẹn , những Node có đầu ra không phụ thuộc vào bất kỳ Node nào bị lỗi, sẽ luôn xuất cùng một giá trị.

Sau khi chấp nhận, các Node sau đó phải xác nhận giá trị đầu ra. Điều này được thực hiện để đảm bảo rằng các Node nguyên vẹn không thể chấp nhận một đầu ra có thể xác nhận rằng đầu ra đó đã được chấp nhận và cũng để thêm bảo mật cho giao thức. Những lý do tại sao điều này là đúng sẽ không được điều trị trong bài viết này.

Về cơ bản, sau khi chấp nhận giá trị đầu ra, mạng lưới các Node sau đó sẽ kiểm tra xem “Này, tất cả chúng ta đã chấp nhận điều này, phải không?” Và xác nhận giá trị, sau đó sẽ được tất cả các Node bên ngoài.

Phiếu bầu

Giả sử có một số lượng tối thiểu các Node bị lỗi, hệ thống sẽ có thể đạt được sự đồng thuận thông qua các lát cắt Quorum ảnh hưởng lẫn nhau. Nhưng tất cả những điều đó vẫn chưa đủ. Tùy thuộc vào sự sắp xếp và số lượng các Node bị lỗi, hệ thống có thể bị kẹt. Nghĩa là, túc số không thể đạt được thỏa thuận về giá trị nào cần được xác nhận.

Nhập phiếu bầu. Để giải quyết vấn đề mạng bị kẹt, SCP thiết lập một hệ thống theo đó tổ chức trưng cầu dân ý để cam kết hoặc hủy bỏ phiếu bầu. Các phiếu bầu được liên kết với các giá trị đầu ra từ các Node. Trước khi họ đủ điều kiện bỏ phiếu, có một quy trình đề cử sẽ loại bỏ những lá phiếu không hợp lệ. Sau đó, các Node sẽ bỏ phiếu để cam kết và chấp nhận một giá trị phiếu bầu hoặc hủy bỏ phiếu bầu, từ chối chấp nhận giá trị cụ thể đó. Do đó, nếu các Node không hoạt động tốt đang xuất ra các giá trị khác nhau, thì chúng có thể bị loại bởi các Node hoạt động tốt.

Có nhiều lý do để làm điều này bằng hình thức bỏ phiếu, chứ không phải là một lá phiếu đơn giản để chấp nhận một giá trị. Các lý do và bằng chứng toán học được cung cấp bởi các định lý có thể được tìm thấy trong sách trắng SCP . Một lưu ý quan trọng là khi bỏ phiếu để chấp nhận một đầu ra, bạn có thể có một cuộc bỏ phiếu chia nhỏ. Tuy nhiên, với lá phiếu, có khả năng loại bỏ các giá trị khỏi việc xem xét, bắt đầu lại quy trình bỏ phiếu và cố gắng đạt được sự đồng thuận với một loạt các lựa chọn hạn chế hơn.

Một lưu ý về bảo mật

Một số khía cạnh khiến mạng vốn dĩ có xu hướng bảo mật hơn, bởi vì, nhưng không giới hạn ở:

• Các Node hoạt động tốt sẽ không muốn giữ các Node bị lỗi trong các lát của chúng, vì nó ảnh hưởng tiêu cực đến chúng, tạo ra sự lựa chọn tự nhiên của các Node “tốt”.
• Việc phân cấp tự nhiên của mạng thành các Nodequan trọng hơn đối với sự đồng thuận xảy ra bởi vì những người tham gia chọn một số Node làm “bên đáng tin cậy” của họ thường xuyên hơn những Node khác. Điều đó đặt các Node mà mạng coi là đáng tin cậy nhất lên hàng đầu.

Hạn chế

Như đã nói bởi người tạo ra nó, David Mazières, SCP có những hạn chế sau:

• Nó không cung cấp một hệ thống để đúc tiền kỹ thuật số.
• Nó không cung cấp một kế hoạch khuyến khích để khuyến khích hành vi tốt từ các Node.
• Nó không cho các Node biết họ có thể tin tưởng ai, có nghĩa là các Node có thể chọn các phần đại biểu không tốt mặc dù họ không có động cơ và có thể gây hại cho sự đồng thuận.

Kết luận & cân nhắc cuối cùng

Giao thức đồng thuận Stellar là sự triển khai đầu tiên của Thỏa thuận Byzantine Liên bang và cung cấp một cách mới để các mạng phân tán đạt được sự đồng thuận. Mặc dù nó là giao thức được sử dụng bởi Mạng Stellar để đạt được sự đồng thuận, nhưng các ứng dụng của nó vượt ra ngoài các Blockchains. Nếu bạn muốn tìm hiểu sâu hơn, bạn có thể truy cập các liên kết bên dưới, cũng được tôi sử dụng làm tài liệu tham khảo cho bài viết này:

• The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus — David Mazières
• David Mazières: The Stellar Consensus Protocol | Talks at Google
• The Stellar Consensus Protocol — David Mazières
• On Worldwide Consensus — Stellar.org
• Ngoài ra, nếu bài viết này đã quá phức tạp, bạn có thể xem: Adventures in Galactic Consensus bởi Stellar.org

Có tham khảo bài viết bởi: Yakko Majuri