Từ sự đồng thuận 1.0 đến 3.0, giao thức Avalanche sắp tới có gì khác biệt?

Nội dung bài viết này đến từ Bihu Live: "Đồng thuận 1.0 đến 3.0, Avalanche sắp tới là gì Giao thức? khác nhau? 》, Ted , kiến trúc sư trưởng của Avalanche và là tác giả của bài báo về sự đồng thuận của dự án Libra của Facebook HotStuff, phân tích những ưu điểm và nhược điểm của các giao thức đồng thuận khác nhau trong chuỗi khối và từ phần kỹ thuật Giới thiệu ngắn gọn về cơ chế đồng thuận của Avalanche. Đặc biệt cảm ơn tác giả Bihu đã tổ chức nó.

Phần sau đây được xuất bản bởi Ted, kiến trúc sư trưởng của Avalanche và là tác giả của dự án Facebook Libra đồng thuận  Giấy HotStuff Tóm tắt ý kiến

Hãy để tôi giới thiệu về bản thân mình trước, Tên tiếng Trung của tôi là Yin Maofan và tên tiếng Anh của tôi là Ted. Tôi hiện là người đồng sáng lập và kiến trúc sư giao thức của Avalanche. Tôi hiện đang là nghiên cứu sinh tiến sĩ tại Cornell, sắp học xong năm thứ tư và sắp bước sang năm thứ năm.

Phiên bản 1.0, 2.0 và 3.0 được đề cập trong tiêu đề chương trình khuyến mãi là các khái niệm được sử dụng trong chương trình khuyến mãi ban đầu của chúng tôi nhằm tạo điều kiện thuận lợi cho việc giới thiệu thuật toán đồng thuận mới của chúng tôi. Hôm nay tôi sẽ chủ yếu giới thiệu những phần dễ hiểu hơn của thuật toán. Trước đây tôi cũng đã nói về kiến trúc tổng thể của hệ thống, dịch vụ nền tảng, v.v.

Để tránh bị nghi ngờ là tiếp thị quá mức, trước tiên hãy để tôi giải thích ý nghĩa của 1.0, 2.0 và 3.0. Có thể coi đây là ba cách cơ bản khác nhau để đạt được sự đồng thuận. Đừng hiểu nó là blockchain 1.0, 2.0, 3.0. Tôi biết rằng blockchain 3.0 đã được quảng cáo rầm rộ trước đây.

Không cần phải lo lắng về các con số. Tôi sẽ nói về tác dụng của từng thuật toán đồng thuận. Mọi người Bạn sẽ có hiểu biết nhất định về điều gì làm cho cách tiếp cận mới dựa trên nền tảng của chúng tôi trở nên độc đáo.

1. Thế hệ đầu tiên, kỷ nguyên của Satoshi Nakamoto

Enter đầu tiên Những gì chúng tôi đang xem xét là những gì cần được khai thác, Bằng chứng công việc (POW). Những ưu điểm và nhược điểm của thỏa thuận này là tương đối rõ ràng.

nó Những gì nó đang cố gắng thực hiện (và Giao thức Satoshi) rất giống nhau. Theo ấn tượng của tôi, có thể đã có những nghiên cứu hay vào những năm 1970 và nó xuất hiện trên sân khấu vào những năm 1980. Đỉnh cao của nghiên cứu đã đạt được trước năm 2000. Có rất nhiều bài viết thảo luận về điều này.

Lý do tại sao nó không ra mắt vào thời điểm đó là vì ngành này không có khái niệm “phân cấp”, “không tin cậy” và minh bạch nền tảng vào thời điểm đó Rất quan tâm. Vào thời điểm đó, những người tiên phong về Internet ở Thung lũng Silicon vẫn đang bắt đầu công việc kinh doanh của riêng mình. Không còn nhiều người nghĩ về một thế giới "không tưởng" hơn nữa.

Trong giao thức thế hệ thứ hai, một tác phẩm tiêu biểu thực sự có thể được áp dụng cho hệ thống là Đồng thuận dung sai lỗi Byzantine thực tế hay gọi tắt là PBFT

1. Ưu điểm

(1) Rất nhanh khi kích thước mạng nhỏ

Một giao thức tương tự như nó, CFT, là một giao thức có thể chấp nhận thời gian ngừng hoạt động và lỗi máy. Giao thức này được sử dụng rộng rãi và là cơ sở hạ tầng được Google, Baidu và Alibaba sử dụng rộng rãi. Đối với các hệ thống cung cấp dịch vụ đám mây, cần đảm bảo hệ thống có thể hiển thị trạng thái hoạt động của mình với thế giới bên ngoài 24 giờ một ngày và 7 ngày một ngày. Để đạt được điều này, cần phải có một mức độ chịu lỗi nhất định. Loại thuật toán này đã được sử dụng trên quy mô lớn. Có thể coi đây là một trong những ứng dụng hỗ trợ nền tảng đám mây hiện nay.

và Nền tảng đám mây tương tự như các giao thức có thể chịu được lỗi thời gian ngừng hoạt động, PBFT cũng nhanh, không yêu cầu khai thác và bảo mật là yếu tố quyết định. Chỉ cần có một ngưỡng dành cho "người xấu", chẳng hạn như dưới một phần ba, có thể đảm bảo rằng một khi hệ thống đưa ra quyết định sẽ không hối hận.

(2) Nó luôn an toàn hơn là an toàn về mặt xác suất

(3) Lịch sử nghiên cứu khoa học tương đối dài

2. Nhược điểm

（ 1) Khó mở rộng

Hệ thống gặp sự cố đáng xấu hổ. Sẽ có "người lãnh đạo" hoặc "điều phối viên" trong hệ thống. Đối với một nút đặc biệt như vậy, nó sẽ trở thành nút cổ chai của toàn bộ hệ thống.

Một số người sẽ nói rằng một số thỏa thuận không cần phải do một người cụ thể lãnh đạo mà mọi người đều bỏ phiếu theo cách hoàn toàn dân chủ. Nhưng trên thực tế, trong trường hợp đó, việc truyền thông trên mạng không tốt bằng sự điều phối của một người. Bởi vì mọi người đều muốn trở thành người lãnh đạo, và ai cũng muốn làm nhiều việc với tư cách là người lãnh đạo, nên về độ phức tạp của thông điệp, hiệu quả không hề được cải thiện mà còn trở nên tồi tệ hơn.

(2) Dựa trên Số đại biểu

Quorum thực sự không thể tìm được bản dịch tiếng Trung nào tốt hơn. Bạn có thể hiểu ngưỡng người ở quốc hội trước đạt giá trị pháp lý là số người tuân theo đa số trong đa số, hay nhóm đạt đa số gọi là Quorum.

Dựa trên thuật toán Quorum chẳng hạn, nếu có 100 người trong hệ thống, tôi hy vọng việc có hơn 66 người sẽ dễ dàng chiếm đa số hơn số phiếu bầu. Thuật toán cần biết chính xác 100% ai đang bỏ phiếu ngay bây giờ. Chúng ta không cần biết cụ thể người nào có đặc điểm gì mà cần biết hệ thống có bao nhiêu người tham gia và yêu cầu thông tin đối với những người tham gia là rất chính xác.

（ 3) Những giả định cứng rắn về “kẻ xấu”

Trong ví dụ trước, khi có hơn 33 "kẻ xấu" trong hệ thống, chẳng hạn như 34 hoặc 40 và hệ thống Nếu chỉ có thể chứa 33 thì tính bảo mật của hệ thống không thể được đảm bảo.

(4) Nhiều giao thức cốt lõi cực kỳ phức tạp

Là một giao thức cấp rất thấp , Đáng lẽ nó tương đối dễ thực hiện, nhưng loại giao thức này, giống như giao thức không phải Byzantine nhưng có khả năng chịu lỗi kép, rất khó triển khai hiệu quả và khó hiểu.

Nhưng vấn đề này cũng đã được cải thiện trong những năm gần đây. Trong dự án nghiên cứu khác của tôi, HotStuff, giao thức được Libra sử dụng đã tối ưu hóa độ phức tạp của chính giao thức đó. Tất nhiên, bản thân giao thức cũng có những hạn chế.

Hình trên là hình tôi thường sử dụng. Nó sẽ mang lại cho mọi người cảm giác trực quan. Quá trình thực hiện loại thỏa thuận này thường là gửi giao dịch với tư cách là khách hàng, giao dịch được phát sóng nhiều lần trên toàn bộ mạng và cuối cùng đạt được sự đồng thuận một cách kỳ diệu.

Năm 2013, một số người cho rằng kiểu thỏa thuận này hoàn toàn không thể hiểu được và tại sao lại đạt được sự đồng thuận sau vài vòng bỏ phiếu nữa. Phim hoạt hình này cũng mang tính châm biếm, hỏi liệu thỏa thuận có thể được thực hiện đơn giản hơn hay không.

                                                ;                       &n bsp ;   ;                           ;                   &nb sp ;       ;   

Cái này Hình ảnh này giải thích điểm nghẽn của giao thức về khối lượng thông tin hoặc hiệu suất trên mạng. Lấy PBFT làm ví dụ, sẽ có quá trình gửi tin nhắn một-nhiều và nhiều-nhiều. Đối với loại mạng này, khi số lượng nút tham gia tăng lên, chi phí của nó thực sự tăng theo bậc bình phương. Trong HotStuff, chúng ta có thể đạt được thứ tự độ lớn tuyến tính, nhưng vấn đề là vẫn sẽ có một nút gửi tin nhắn đến tất cả các nút, điều này hiện không thể tránh khỏi.

Chúng tôi đã giới thiệu hai loại đồng thuận chính trước đó. Hầu như tất cả các giao thức mà tôi biết ngày nay đều bắt nguồn từ hai mô hình tiêu chuẩn này. Miễn là nó không ngẫu nhiên, dựa trên một trong hai điều này, sau đó tối ưu hóa hiệu suất hoặc thêm một số tính năng bổ sung, thì cốt lõi về cơ bản vẫn không thay đổi.

Cái này Điều này có thể dẫn đến sự đồng thuận của thế hệ thứ ba mà chúng ta sẽ tập trung vào hôm nay.

Thế hệ thứ ba, thứ ba, Thỏa thuận tuyết lở

Hóa ra tên trên báo là Avalanche, dịch sang tiếng Trung là 雪碰. Nhiều người cho rằng cái tên này kém may mắn. Tôi đã biết ngay từ đầu, nhưng có lẽ lúc đầu đó là dự án được thực hiện ở Mỹ, không ai (trừ tôi) hiểu tiếng Trung và không có nhiều thiện cảm, mặt khác tôi nghĩ cũng không sao cả. Suy cho cùng, chúng ta đều là thế hệ mới, không mấy quan tâm đến những cái tên đồng âm. Ngược lại, việc có những cái tên đồng âm không hẳn là điều xấu. Khi tiến lên, bạn nói rằng bạn rất mạnh mẽ, nhưng thái độ quá cao sẽ không tốt. Chúng tôi mắc kẹt với cái tên đó.

Lở tuyết Đây là bản dự thảo đầu tiên chúng tôi gửi tới IPFS vào tháng 5 năm 2018. Như bạn có thể thấy, sau một năm sửa đổi, nội dung chính không có nhiều thay đổi và hiện tại về cơ bản đã hoàn thiện.

Một sự trùng hợp đáng tiếc là mô hình chúng tôi sử dụng để thực hiện giao thức này là mô hình bệnh truyền nhiễm. Trong giai đoạn đặc biệt này, chúng ta có thể hiểu theo một cách khác, tương tự như mô hình lan truyền tin đồn.

Tại sao một thứ nghe có vẻ không thể đạt được với tám cực lại liên quan đến sự đồng thuận và blockchain? Tôi sẽ đưa ra ví dụ trong giây lát.

1. Ưu điểm

Thật ra cả hai Nó có ưu điểm của hai loại đồng thuận đầu tiên.

(1) Sự xuống cấp về bảo mật là điều dễ hiểu

Tương tự như sự đồng thuận của Satoshi Nakamoto, nó sẽ không hoàn toàn không thể sử dụng được sau khi "kẻ xấu" đạt đến ngưỡng.

(2) Yêu cầu về thông tin thành viên tương đối lỏng lẻo

Thế giới tôi nhìn thấy và bạn Có một số khác biệt trên thế giới được nhận thấy giữa các cá nhân tham gia, nhưng nhìn chung thì khá giống nhau.

（ 3) Bỏ qua kích thước mạng và bạn sẽ sớm hoàn thành

Đây là lợi thế lớn nhất hoặc là điều thu hút tôi. Trong giao thức, không có nút nào cần giao tiếp với tất cả các nút khác, thay vào đó, mỗi nút là ngang hàng và chỉ có thể giao tiếp với một số lượng nút không đổi hoặc rất nhỏ trong mạng.

Cũng giống như việc tin đồn lan truyền trong xã hội thực, không phải phát bằng loa nói chuyện này là sự thật mà là tôi và vài chục người Bạn bè bàn tán, không hiểu sao cả làng đều biết.

(4) Xanh và thân thiện với môi trường

Toàn bộ quá trình thỏa thuận không yêu cầu khai thác. Tương tự như loại thỏa thuận thứ hai, nó chỉ yêu cầu bỏ phiếu và không yêu cầu khai thác. Điều này có nghĩa là không có thời gian chờ đợi lâu cho các giao dịch.

(5) Giao thức phù hợp về mặt trực quan với thực tế

Tất nhiên chứng minh toán học là rất phức tạp. Nó được đề cập trong bài viết này, nhưng tất nhiên không cần phải ai cũng hiểu nó.

Kết nối Tiếp theo, tôi sẽ cố gắng giải thích một cách khái quát cách thức hoạt động của sự đồng thuận từ góc độ trực quan.

Chúng tôi tưởng tượng một nhóm người, chẳng hạn như một trăm hoặc một nghìn người, đang thảo luận xem một người nào đó trong ngành giải trí là thật hay giả . Nói cách khác, điều này không thể hiểu được đối với mọi người, chúng tôi xem xét một mạng có N nút tham gia vào sự đồng thuận nhị phân, điều này là đúng hoặc sai.

Theo giả định này, chúng tôi cho phép mỗi Cá nhân lựa chọn K cá thể một cách độc lập và tự do một cách ngẫu nhiên. Ví dụ: trong bối cảnh 100 người của chúng tôi, giả sử rằng mỗi người lấy mẫu ngẫu nhiên mười người cùng một lúc. Lấy mẫu có nghĩa là có người, Zhang San, sẽ hỏi mười người này xem tin đồn có phải là sự thật không? Đây là một cuộc điều tra hoặc một mẫu. Bằng cách kiểm tra kết quả của mẫu K, liệu hầu hết mọi người có nghĩ rằng việc cập nhật xu hướng thực tế của Zhang San là có thật hay không, tôi thiên về việc đó là đúng hay sai.

So với các giao thức dựa trên biểu quyết khác, quy trình này có một thay đổi lớn và cần thiết ở chỗ nó không cần giao tiếp với mọi người (nút) trong toàn bộ mạng mà chỉ cần lấy xấp xỉ K từ N người. Và K có thể rất nhỏ.

Ví dụ mình hỏi 10 người trên mạng 100 người thì mình vẫn hỏi 10 người trên mạng 1000 người.

k Sự lựa chọn liên quan đến mức độ bảo mật bạn cần và về cơ bản không liên quan gì đến quy mô của mạng. Về mức độ bảo mật mà tôi cần, mức độ gần đúng giữa một mạng có 1.000 người tham gia và một mạng có 100 triệu người tham gia là gần như nhau. Bởi vì chúng tôi thấy rằng theo thống kê, việc lấy mẫu có thể gần đúng tổng thể, do đó, ở một mức độ lớn, kích thước của truy vấn và kích thước của mạng có thể được tách riêng ở một mức độ nhất định mà không cần phải hỏi tất cả mọi người.

Tôi thấy một bình luận trong đó có người hỏi liệu chi phí lấy mẫu có cao không. Chi phí là chi phí truyền thông mạng, ví dụ: nếu tôi gửi tin nhắn đến mười nút, chi phí này thấp hơn nhiều so với chi phí gửi tin nhắn cho mọi người như khai thác và bỏ phiếu. Điều này giúp tiết kiệm phần lớn chi phí gửi tin nhắn tới toàn mạng.

Hãy lấy một ví dụ cụ thể hơn. Như hình dưới đây.

Ví dụ: Zhang San là nút trên cùng. Lúc đầu, anh ấy nghĩ đó là hàng giả và chúng tôi đánh dấu bằng màu cam. Anh hỏi năm người và nhận thấy hầu hết đều nói với anh rằng đó là sự thật. Lúc này, Zhang San nhận thấy quan điểm chủ đạo và xu hướng hiện tại của mình dường như thiên về cánh tả, và anh ấy có thể sẽ điều chỉnh.

Và Li Si cũng đang hỏi người mà anh ấy đang lấy mẫu, việc này xảy ra đồng thời. Về việc Lý Tư có thể là thật lúc đầu, tôi hỏi ngẫu nhiên năm người và phát hiện ra rằng hầu hết mọi người đều nói với anh ấy rằng đó là sai.

Tình trạng này cho thấy Internet vẫn đang trong giai đoạn tranh luận. Giống như một chủ đề được tìm kiếm rất nóng, ngoài fan ra còn có fan và những người tham gia tranh luận, không hề có tình trạng một chiều.

Trong mọi trường hợp, Zhang San và Li Si có thể điều chỉnh sở thích của mình sau mỗi lần yêu cầu. Tôi sẽ điều chỉnh quan điểm của mình dựa trên những ý kiến chủ đạo hiện tại. Quá trình này được minh họa dưới đây.

Quy trình này là một quy trình động.

Liên kết này là một chương trình nhỏ mà tôi đã dành thời gian để viết vào năm ngoái. Tôi đã biến quy trình này thành một hình ảnh động, có thể mô phỏng quá trình này. Bạn có thể đặt kích thước mạng và xem sự đồng thuận nhị phân được hình thành như thế nào.

Mặc dù đường cong bên dưới sẽ trông quen thuộc với mọi người vì nó được lấy cảm hứng từ mô hình bệnh truyền nhiễm. Nhưng đừng tưởng tượng rằng nó dựa trên sự lây nhiễm hoặc không lây nhiễm. Nó giống như hai quan điểm cạnh tranh với nhau hơn.

Để tóm tắt về Avalanche. Nó sử dụng phương pháp lấy mẫu và có thể được coi là một hệ thống bỏ phiếu tổng quát dựa trên đa số tuân theo đa số. Không cần bằng chứng về công việc. Vì vậy Avalanche có lợi thế của hai sự đồng thuận đầu tiên. Mạng nhanh đến mức nào, về mặt lý thuyết có thể chạy nhanh đến mức nào. Nó cũng có thể dễ dàng mở rộng quy mô một số lượng lớn các nút. Không có hạn chế nghiêm ngặt về thành viên.

Mọi người có thói quen gọi bất kỳ giao thức nào không được viết bởi Satoshi Nakamoto là giao thức PoS. Lý do chính là cơ chế truy cập. Nói đúng ra, để có được sự đồng thuận, việc tiếp cận không phải là vấn đề cần giải quyết. Mọi người đều đề cập đến thuật toán đồng thuận là PoW hay PoS. Tuyên bố này về cơ bản là sai. Vấn đề là liệu bản thân hệ thống đó dựa trên PoW hay PoS hay nó là loại cơ chế tiếp nhận nào.

Cơ chế đồng thuận và cơ chế truy cập không tự nhiên có liên quan với nhau. Chỉ là Satoshi Nakamoto tình cờ ghép đôi hai người đó thôi. Đối với bất kỳ giao thức nào không dựa trên hoạt động khai thác của Satoshi Nakamoto, cần có cơ chế tiếp nhận bổ sung.

Về mặt này, chúng tôi cũng giống như các giao thức khác không yêu cầu khai thác. Nói cách khác, bạn có thể thử giới thiệu bất kỳ cơ chế truy cập nào, chẳng hạn như sử dụng PoS làm cơ chế.

Do thời gian có hạn nên gần như chỉ có ngày hôm nay. Tiếp theo là phần hỏi đáp.

4. Hỏi đáp mang tính tương tác

1 , Giới thiệu về biểu đồ tuần hoàn có hướng

Bạn có thể thấy rằng tôi đã không nói về biểu đồ tuần hoàn theo hướng DAG trong một thời gian dài. Đây là điều bị hiểu lầm nhiều nhất về loại thỏa thuận này.

Bản thân DAG không thể đạt được sự đồng thuận, nó chỉ là một phương tiện tối ưu hóa. Nếu bạn thấy bất kỳ dự án nào sử dụng DAG để đồng thuận, tôi nghĩ bản thân tuyên bố này đã sai.

Đối với các trường hợp DAG khác, Confiux tương đối đáng tin cậy sử dụng biểu đồ chu kỳ có hướng cộng với sự đồng thuận của Nakamoto để cố gắng sử dụng DAG nhằm cải thiện thông lượng của sự đồng thuận của Nakamoto. số lượng. Bản thân DAG không làm cho sự đồng thuận tốt hơn. Nó tăng thông lượng nhưng không thể thay đổi độ trễ hoặc tách rời các yêu cầu thông qua DAG. Tất cả các giao dịch ban đầu yêu cầu giao dịch tuyến tính phải được thực hiện thành một chuỗi. Bây giờ bạn có thể có các giao dịch không liên quan xảy ra đồng thời và thời gian không thành vấn đề.

DAG chúng tôi sử dụng trong Avalanche là DAG sau. Nếu phần lớn công việc là giao dịch và chuyển giao tài sản thì các giao dịch không cần phải theo thứ tự nghiêm ngặt và việc sử dụng DAG có thể cải thiện đáng kể khả năng đồng thời của hệ thống.

2. Avalanche giải quyết các vấn đề về truyền khối và không xác nhận như thế nào? Ưu điểm so với các công nghệ khác là gì? Đâu là điểm kỹ thuật cốt lõi?

Tôi hoàn toàn không hiểu việc truyền bá khối và xác nhận bằng 0 đề cập đến điều gì . Tôi sẽ thực hiện một số cuộc thảo luận sâu rộng về giao tiếp của các khối trong chuỗi khối.

Thuật toán Avalanche không được phát trên toàn mạng trong quá trình liên lạc vì không có nút nào thực hiện việc này. Nó sẽ có lợi thế là không phải nhắn tin cho tất cả mọi người cùng một lúc. Có lẽ bạn không cảm thấy sự khác biệt? Chỉ cần nhắn tin cho một nhóm nhỏ và nhắn tin cho tất cả mọi người. Nhưng sự khác biệt về tác động kỹ thuật và kỹ thuật vẫn còn rất lớn.

Chúng ta có thể tưởng tượng rằng nếu một nút trở thành mục tiêu chỉ trích của công chúng và mọi người gửi tin nhắn đến nút đó thì khả năng tải của nút này sẽ không thể chịu nổi. Bởi vì chúng tôi giả định rằng các nút tham gia tương đối bằng nhau. Sẽ không có nút đặc biệt nào là siêu máy tính, còn lại là điện thoại di động. Nếu ở tình huống ngang hàng, nút đó (phát tới toàn bộ mạng) sẽ trở thành nút cổ chai.

Nhưng nếu bạn hỏi về cách các khối được phân phối thì chúng tôi giống Bitcoin hơn về mặt này. Chúng tôi cũng lan truyền nó thông qua các mạng tin đồn tương tự. Nó gần giống với sự đồng thuận vừa rồi. Về mặt thiết kế, các phương thức phổ biến, đồng thuận và giao tiếp đều giống nhau.

3. Avalanche có bốn giao thức phụ: Slush, Snowflake, Snowball và Avalanche. Bạn có thể giải thích ngắn gọn sự khác biệt và mối liên hệ giữa chúng không?

Người dùng này rõ ràng đã xem bài viết của chúng tôi. Bốn giao thức được đề cập trong bài viết của chúng tôi vẫn nhằm mục đích giúp mọi người dễ hiểu.

Tóm lại, giao thức chịu lỗi Byzantine thực sự có thể được sử dụng là giao thức Snowball. Slush Snowwater Protocol không phải là Byzantine Fault Tolerant mà dựa trên mạng tin đồn trước đó để xem liệu nó có thể thực hiện những điều nhất quán hay không. Bông tuyết có thể tạo ra Byzantium, nhưng sẽ có một số vấn đề về sức sống. “Kẻ xấu” có thể liên tục kéo hệ thống không cho nó nghiêng sang một bên, để một loại sóng âm chiếm ưu thế và có thể quét toàn bộ mạng trong thời gian ngắn. Nó duy trì sự cân bằng này.

Snowball thêm một chút hiệu ứng quả cầu tuyết vào nó. Nói cách khác, mạng này không hoàn toàn không có bộ nhớ và mọi người đều có mức độ tin cậy nhất định về trạng thái mà họ xác nhận. Mức độ tin cậy này không thể bị buộc phải thay đổi sang quan điểm khác sau khi được xác nhận trong một khoảng thời gian ngắn. Nếu tôi thừa nhận sự thật này, tôi sẽ không đột ngột nhảy sang phía bên kia vì một mẫu nào đó của tôi, mà tôi sẽ ở một bên rất ổn định.

Cuối cùng, Avalanche là một hệ thống được tối ưu hóa dựa trên Snowball để hỗ trợ các giao dịch thuần túy. Sau đó, chúng tôi cũng xây dựng một hệ thống khác dựa trên Snowball, Snowone, được dự định sử dụng làm chuỗi cho các hợp đồng thông minh và chuỗi để quản trị blockchain.

4. Vui lòng hỏi những câu hỏi sau: 1. Thuật toán giao thức có đề cập đến thuật toán bầy đàn hạt không? Tính nhất quán và hội tụ của thuật toán đã được kiểm chứng chưa?  2. Nút không lưu toàn bộ dữ liệu khối? Làm thế nào để truy tìm nguồn gốc của toàn bộ dữ liệu khối?

Đây là một câu hỏi rất hay. Những người có nền tảng về vật lý và hóa học sẽ nghĩ đến thuật toán này, thuật toán bầy hạt hoặc mô hình người ngoài hành tinh trong vật lý.

Tôi không đặc biệt quen thuộc với các lĩnh vực khác. Thuật toán bầy hạt mà bạn đang nói đến có thể đề cập đến một loại, nếu mỗi nút trong chế độ vận hành giao thức được coi là một hạt cơ bản. Nếu giao thức được coi là một hạt cơ bản tương tác với các hạt xung quanh theo các định luật vật lý cơ bản thì nó có thể được coi là một loại thuật toán bầy hạt. Tính nhất quán và hội tụ của chúng tôi là hợp lý về mặt lý thuyết.

Câu hỏi thứ hai là, nếu nút hiện tại của chúng ta tham gia vào mạng con A thì tất cả dữ liệu trong mạng con A sẽ vẫn được lưu. Thuật toán chính thống hiện tại được sử dụng trong các dự án khác cũng giống như thuật toán lưu dữ liệu trên toàn bộ chuỗi. Tất nhiên, do có mạng con nên không cần lưu toàn bộ chuỗi nhưng dữ liệu của chuỗi bạn quan tâm thì phải lưu lại.

Trong tương lai, chúng tôi cũng sẽ xem xét liệu có cho phép mọi người lưu toàn bộ dữ liệu và thực hiện một số tối ưu hóa để linh hoạt hay không. Tuy nhiên, cần lưu ý rằng việc không lưu toàn bộ dữ liệu thực chất là sự thỏa hiệp về khả năng chịu lỗi. Từ bỏ một mức độ chịu lỗi nhất định để giảm lượng thông tin dư thừa trong mạng hoặc lượng dữ liệu mà mỗi nút duy trì.

5. Chúng tôi thấy rằng mạng thử nghiệm AVA nhận được thông số tps khoảng 3400 và độ trễ xác nhận là 1,35 giây. Một số dự án thường tuyên bố đạt 1 triệu tps, nhưng kết quả này có vẻ không nổi bật lắm, điểm nghẽn của hiệu suất này là gì? Hiệu suất sẽ như thế nào khi mạng chính trực tuyến?

Đây là một câu hỏi phổ biến. TPS chỉ là một chỉ báo đo lường số lượng giao dịch mà mạng có thể thực hiện. Nếu chỉ nhìn vào TPS, chúng ta có thể tưởng tượng rằng nếu tôi sử dụng SF Express hoặc China Post và sử dụng xe tải chuyển phát nhanh để vận chuyển một khối lượng ổ cứng hoặc thẻ SD từ Thượng Hải đến Bắc Kinh, ngay cả khi phải mất hai hoặc ba ngày mới đến nơi, do lượng thông tin được mang theo lớn nên thông lượng trung bình sẽ cao hơn bất kỳ dự án blockchain nào. Nhưng bạn có thể sử dụng chuyển phát nhanh để tạo blockchain không? Tôi không nghĩ vậy.

Ngoài việc xem xét thông lượng, bạn cũng cần xem xét độ trễ. Đối với người dùng thông thường, họ thực sự không quan tâm nhiều đến việc toàn bộ hệ thống có thể đáp ứng được bao nhiêu. Khi sử dụng Alipay, bạn không quan tâm đến thông lượng của Alibaba mạnh đến mức nào mà quan tâm hơn đến thời gian trung bình để một giao dịch được gửi từ khi gửi đến khi xác nhận. Vì vậy, chúng ta cần nhìn mọi thứ theo hai hướng.

6. Tính bảo mật của từng mạng con có được mạng AVA duy trì không? Hay chúng có thiết kế tương tự như sidechains, với tính bảo mật độc lập với mạng chính?

Bạn muốn nói rằng trạng thái của chuỗi bên và chuỗi chính không bằng nhau? Vì vậy, về cơ bản không có sự đồng thuận về chuỗi bên?

Trên thực tế, trong thiết kế của chúng tôi, chuỗi bên không được đề cập đến. Vấn đề mà chúng tôi hy vọng giải quyết được không phải là chuyển mâu thuẫn chính sang chuỗi bên hoặc chuỗi không chính để hoàn thành cái gọi là cải thiện hiệu suất.

Chúng tôi đề xuất mạng con, chủ yếu nhằm mục đích sử dụng hoặc cải thiện trải nghiệm người dùng. Chúng tôi nhận ra rằng hệ thống phải có mạng chính để đưa ra các quyết định cốt lõi và quan trọng. Tương tự, mọi người cũng muốn điều hành chuỗi con, chuỗi của riêng mình. Theo lý thì chúng ta có thể yêu cầu mọi người tự mình điều hành, nhưng thực tế sẽ không có ai làm nhiều như vậy, không cần thiết.

Đầu tiên là có thể mọi người không sẵn lòng làm điều đó. Có thể bản thân chuỗi con chỉ để cho vui thôi, vậy tại sao nó lại giúp bạn nâng cao tính bảo mật của chuỗi? Mặt khác, nếu tôi làm điều đó, tôi có thể tính phí và đáp ứng các yêu cầu về tài chính. Đó sẽ là một tổn thất lớn đối với các sub-chain chỉ muốn chơi và không cần mọi người tham gia (họ không có động lực để làm điều đó).

Vì vậy chúng tôi đã thêm mạng con để làm cho hệ thống linh hoạt hơn. Bạn có thể tưởng tượng rằng dù thế nào đi nữa thì tất cả trẻ em đều phải đến trường, các lớp ở trường là mạng chính và các mạng con là các lớp sở thích. Bạn chỉ có một đứa con, nhưng bạn có thể cho nó tham gia các lớp học có sở thích khác nhau. Cả mạng con và mạng chính đều hoàn thành các mục đích tương ứng. Thuật toán là một thuật toán và không có vấn đề bảo mật. Số lượng người tham gia có thể khác nhau, nếu số lượng người tham gia mạng con quá ít thì khả năng chịu lỗi thực sự sẽ thấp hơn mạng chính, nhưng điều này chỉ là do số lượng nút tham gia không đủ.

7. Điểm tương đồng và khác biệt giữa Avalanche với Cosmos và Polkadot trong thiết kế chuỗi chéo là gì? Khi một dự án muốn truy cập chuỗi chéo của Avalanche, trước tiên nó sẽ cần xây dựng một mạng lưới phân nhánh dựa trên kiến trúc cơ bản của AVA. Thiết kế này có làm tăng các rào cản sử dụng không?

Tôi sẽ không nói về các dự án khác. Hãy nói về cách chúng tôi thực hiện chuỗi chéo. Chúng tôi cũng sử dụng "trao đổi nguyên tử", hiện đang được nghiên cứu rất sôi nổi, để đạt được chuỗi chéo. Chúng tôi cũng tiến hành thiết kế và trình diễn một cách có hệ thống.

Hiện tại có chuỗi chéo trên hệ thống. Chúng tôi có một chuỗi để kiểm soát những người tham gia, bởi vì việc tham gia đòi hỏi phải đặt cọc, tức là đặt cược. Chúng tôi có một chuỗi dành riêng cho việc đặt cược. Chuỗi này cũng là một chuỗi để quản trị. Nó cũng có sự đồng thuận riêng, đó là sự đồng thuận tuần tự.

Đối với Avalanche, không yêu cầu tất cả các giao dịch phải có cấu trúc tuyến tính, nhưng miễn là không có xung đột giữa chúng, chúng có thể được thực hiện tại cùng thời điểm họ muốn. Chuỗi chéo là việc sử dụng phương pháp Fanyong. Tôi không chắc chính xác Cosmos và Polkadot sử dụng phương pháp nào, nhưng ít nhất phương pháp của chúng tôi có thể đáp ứng nhu cầu giữa các chuỗi trong hệ thống.

Chuỗi chéo mà chúng ta đang nói đến ở đây không phải là chuỗi chéo giữa ava và các dự án khác. Về vấn đề này, về cơ bản, chúng tôi khác biệt với các công ty khởi nghiệp và dự án tập trung vào các dịch vụ chuỗi chéo. Chuỗi chéo nội bộ của chúng tôi là một hệ thống doanh thu nội bộ, bởi vì sự đồng thuận được sử dụng là như nhau nên không có nhiều vấn đề.

8. Avalanche không thể được gọi là một chuỗi, phải không?

Đây là một câu hỏi triết học rất hay và là một sự tra tấn tâm hồn. Nó phụ thuộc vào định nghĩa của bạn về blockchain. Chuỗi khối là gì? Nếu xác định rõ vấn đề này, dù có gọi là chuỗi hay không thì những việc đã làm và dịch vụ cung cấp đều giống nhau, có gì khác nhau?

9. Sự khác biệt giữa Avalanche và showone là gì?

Bạn có thể hiểu rằng Showone giống loại dây chuyền mà bạn hiểu hơn, hoàn thiện sự đồng thuận từng bước một, trong khi Avalanche giống một cấu trúc ngẫu nhiên hơn. Mọi người hãy tự mình đi và giải quyết vấn đề của hai người các bên thông qua thuật toán đồng thuận. Avalanche rõ ràng sẽ nhanh hơn Showone hoặc dễ dàng mở rộng quy mô hơn. Nhưng hạn chế là nó không thể hỗ trợ trực tiếp các hợp đồng thông minh. Đó là lý do tại sao chúng tôi cảm thấy rằng chúng tôi có thể kết hợp hai giao thức có cùng nguồn gốc, điều này sẽ giải quyết hoàn hảo nhu cầu hiện tại.

10. Có thể kết hợp đồng thuận và khai thác Avalanche không?

Tôi nhớ có người đã thực sự đề cập đến ý tưởng này cách đây hơn một hoặc hai năm. Họ đã thực hiện "đồng thuận trước" dựa trên giao thức của chúng tôi. Họ hy vọng sử dụng sự đồng thuận của chúng tôi để tăng tốc độ xác nhận giao dịch trước, sau đó sử dụng PoW chậm để xác nhận cuối cùng.

11. Câu hỏi về việc gây quỹ:

Vì có quá nhiều người muốn đăng ký theo dõi phát hành riêng tư, vì vậy chúng tôi đã lắng nghe ý kiến của cộng đồng và đưa ra các giải pháp khác nhau. Trong khi đảm bảo sự công bằng trong phân phối mã thông báo, chúng tôi cố gắng hết sức để phát triển cùng với dự án và đảm bảo tính công bằng và cởi mở của việc phân phối mã thông báo

Vì vậy, chúng tôi có ba tùy chọn: Tùy chọn A1: 0,5 USD/coin, khóa trong một năm, mua tối đa 25 nghìn USD. Tùy chọn A2: 0,5 USD/coin, khóa trong 1,5 năm, không giới hạn trên. Tùy chọn B: 0,85 USD/coin, không khóa, tối đa 5k mỗi người

Thời gian là 7.8 bắt đầu lúc 10 giờ tối theo giờ Bắc Kinh. Bạn có thể xem các kênh mua và thông tin bán mã thông báo Avalanche (chọn tiếng Trung ở góc dưới bên phải): https:// info.avax.network/

(Báo cáo nhịp điệu:《 Mã thông báo Giao thức Avalanche AVAX sẽ được bán công khai vào ngày 8 tháng 7, với 3 tùy chọn mua có sẵn 》)

Về trao đổi, chúng tôi đã liên hệ với các sàn giao dịch hàng đầu trong ngành và hy vọng sẽ tiếp cận được nhóm người dùng đủ lớn và chất lượng cao khi nó lên mạng, vì vậy hãy chờ đợi vì tiến độ trong tương lai của chúng tôi, chúng tôi sẽ phát hành mạng chính vào mùa hè này, vì vậy hãy chờ đợi.

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia