Việc sử dụng băng thông của Algorand hiệu quả như thế nào? Còn Ouroboros của Cardano thì sao? Tại sao Solana và NKN có thể có TPS cao như vậy? Ethereum đã rút ngắn khoảng thời gian chặn xuống còn 15 giây, tại sao nó không cao hơn nhiều so với thông lượng Bitcoin?
Bác sĩ Zhang Ren sẽ lần lượt giải đáp những thắc mắc này trong bài chia sẻ. Sau đây là bản ghi lại bài phát biểu của Tiến sĩ Ren.
Đọc bài viết này có một số yêu cầu nhất định đối với kiến thức cơ bản về blockchain của người đọc:
Khái niệm cơ bản về giao thức đồng thuận Bitcoin (nghĩa là Đồng thuận Nakamoto)
Các khái niệm cơ bản về giao thức đồng thuận Ethereum
Khối mồ côi, khối chú, khai thác ích kỷ và các khái niệm khác
Liên kêt video:
Liên kêt video:https://v.qq.com/x/page/g0837...
Để tôi tự giới thiệu. Tôi là Zhang Ren, một nhà nghiên cứu tại Nervos & Cryptape. Tôi hiện đang là nghiên cứu sinh tiến sĩ tại COSIC (nhóm Bảo mật máy tính và Mật mã công nghiệp) tại KU Leuven, dưới sự hướng dẫn của Bart Preneel. Nếu bạn không quen thuộc với COSIC, tôi tự hỏi liệu bạn đã nghe nói về AES chưa, tiêu chuẩn mã hóa được sử dụng trong tất cả các điện thoại di động của chúng tôi.
Tất nhiên, nếu bạn đã quen thuộc với Bart Preneel, bạn sẽ biết rằng anh ấy là nhà thiết kế của RIPEMD 160. RIPEMD 160 là thuật toán băm được sử dụng khi chuyển đổi khóa công khai Bitcoin thành địa chỉ Bitcoin.
Nervos CKB là một chuỗi công khai có thể hỗ trợ các hợp đồng thông minh bằng nhiều ngôn ngữ lập trình và các giao thức Lớp 2 khác nhau. Trên Nervos CKB, bạn có thể sử dụng bất kỳ tài sản nào để thanh toán phí giao dịch. Việc thực thi và xác minh các hợp đồng thông minh trong Nervos CKB được tách biệt để đạt được hiệu suất và quyền riêng tư tốt hơn. Cuối cùng, NC-Max—một biến thể của Đồng thuận Nakamoto—được chấp nhận trong Nervos CKB như một giao thức đồng thuận với thông lượng cao hơn.
Tuyên bố miễn trừ trách nhiệm: Nội dung chia sẻ này chỉ tập trung vào việc phân tích các giao thức đồng thuận Lớp 1 và tôi sẽ không nói về các giải pháp Lớp 2 như Lightning Network.
tiêu đề phụ
Tại sao chúng ta yêu thích NC của Bitcoin?
Trước tiên, hãy trả lời một câu hỏi, tại sao chúng ta thích Đồng thuận Nakamoto (NC) của Bitcoin?
Có nhiều lý do, trước hết là khả năng tối ưu hóa hiệu suất của NC rất tốt, nó có thể tiết kiệm từng byte của mỗi lần truyền và mỗi chu kỳ tính toán. Ví dụ: nó sử dụng Khối nhỏ gọn để tăng tốc độ truyền khối và trong tương lai có thể sử dụng Minisketch (thư viện phần mềm được sử dụng để giảm yêu cầu băng thông khi đồng bộ hóa thông tin giữa các nút khác nhau trong hệ thống phân tán) để tiết kiệm tài nguyên băng thông. Đồng thời, các nhà phát triển Bitcoin đã đề xuất Graftroot (một đề xuất liên quan đến phát triển hợp đồng thông minh và quyền riêng tư trên Bitcoin), bạn có thể nghĩ rằng nó có thể đạt được quyền riêng tư và bảo mật tốt hơn bằng cách nén hiệu suất hợp đồng thông minh trên Bitcoin. Có lẽ chúng ta cũng có thể thấy Tổng hợp chữ ký được áp dụng cho Bitcoin.
Điểm kiến thức: Chuyển tiếp khối nhỏ gọn, được đề xuất trong Giao thức cải tiến Bitcoin (BIP) 152, có thể giảm lượng băng thông cần thiết cho các nút mạng P2P để phát các khối.
Khối nén là “bản tóm tắt” của khối hoàn chỉnh, bao gồm 3 phần thông tin sau:
1. Tiêu đề khối của khối mới
2. ID giao dịch
3. Giao dịch hoàn chỉnh được dự đoán bởi nút gửi nhưng không có sẵn cho nút nhận
Người nhận cố gắng xây dựng lại toàn bộ khối dựa trên thông tin nhận được và các giao dịch trong mempool của nó. Nếu một số giao dịch vẫn bị thiếu, nó sẽ yêu cầu nút quảng bá.
Một lý do khác để thích NC là tính linh hoạt của nó. Mô hình UTXO cộng với đơn đặt hàng giao dịch toàn cầu có thể hỗ trợ các công nghệ sharding và sơ đồ Lớp 2 khác nhau, cũng như các hợp đồng thông minh phức tạp.
Để so sánh, mô hình Tài khoản của Ethereum khó phân mảnh hơn và nếu bạn không có lệnh giao dịch toàn cầu, chẳng hạn như nhiều giao thức kiểu DAG, thì rất khó để hỗ trợ các hợp đồng thông minh phức tạp. Phần này sẽ được mô tả chi tiết khi nói về DAG sau này.
Chúng tôi cũng thích tính bảo mật của Bitcoin NC. Mạng Bitcoin đã trải qua nhiều cuộc tấn công và đã hoạt động ổn định trong mười năm. Và nói đúng ra, hiện tại không có cơ chế đồng thuận bằng chứng công việc nào vượt qua NC nói chung. Nếu bạn quan tâm đến chủ đề này, bạn có thể xemđây.
tiêu đề phụ
Chúng ta cần thay đổi NC ở đâu?
Như đã lưu ý trong nghiên cứu ở trên, các nút Bitcoin IPv4 được kết nối với mạng có băng thông trung bình là 33Mbit/s vào năm 2016 và 56Mbit/s vào tháng 2 năm 2017.
Phương pháp cải tiến mà chúng ta có thể dễ dàng nghĩ đến là liệu bản thân giao thức có thể tự động điều chỉnh thông lượng để thích ứng với sự thay đổi của mức băng thông hay không?
Bitcoin Unlimited đã thực hiện một nỗ lực không tốt trong việc tự động điều chỉnh thông lượng của Bitcoin, nhưng nó đã thất bại và đưa ra nhiều vectơ tấn công mới để làm cho giao thức của nó không an toàn. Trên đây là nghiên cứu về tính bảo mật của Bitcoin Unlimited được công bố trên Coindesk (link:https://www.coindesk.com/etf-...), và tôi cũng là một trong những người tham gia nghiên cứu này.
Một điều khác mà chúng tôi hy vọng sẽ thay đổi trong NC là vấn đề khuyến khích của nó, đó là vấn đề của các cuộc tấn công khai thác ích kỷ. Những kẻ tấn công khai thác ích kỷ giữ lại các khối được phát hiện với hy vọng giành được vị trí dẫn đầu lớn hơn trong mạng. Khi những người khai thác trung thực khác phát hiện ra khối, kẻ tấn công sẽ phát khối bị giữ lại lên mạng, hy vọng rằng hầu hết những người khai thác trung thực sẽ nhận được khối bị giữ lại trước khối trung thực. Nếu kẻ tấn công đủ may mắn để khối tiếp theo được khai thác trên khối của kẻ tấn công, khối trung thực sẽ bị bỏ rơi. Nếu kẻ tấn công đủ may mắn để khai thác nhiều khối liên tiếp, sẽ rất an toàn để vô hiệu hóa khối của người khai thác trung thực vì kẻ tấn công sẽ có chuỗi dài hơn.
Tại sao khai thác ích kỷ có lãi? Hãy lấy một ví dụ cụ thể, giả sử rằng những kẻ tấn công khai thác ích kỷ có 30% sức mạnh tính toán của toàn bộ mạng và những người khai thác trung thực kiểm soát 70% còn lại. Nếu không có cuộc tấn công khai thác ích kỷ, thì kẻ tấn công có thể tìm thấy 3 trong số 10 khối, những người khai thác trung thực có thể tìm thấy 7 và mọi người đều nhận được phần thưởng xứng đáng. Nếu kẻ tấn công khởi động một cuộc tấn công khai thác ích kỷ, thì nó có thể tìm thấy 3 khối và những người khai thác trung thực chỉ có thể tìm thấy 4 khối, bởi vì các khối được tìm thấy bởi 3 thợ mỏ trung thực khác đã trở thành các khối mồ côi thông qua phương pháp tấn công nói trên, thời điểm mà 10 khối có thể đã được tạo ra hiện chỉ có 7 khối và tốc độ tăng trưởng của chuỗi chính đã chậm lại.
tiêu đề phụ
Các giao thức đồng thuận thay thế khác
Vậy tại sao chúng ta không chọn các giao thức đồng thuận thay thế khác?
Hiện tại có ba cách để thay thế NC, đó là PoS (Proof of Stake, bằng chứng về quyền và lợi ích), DAG và các giao thức đồng thuận của hai loại khối. Lưu ý 3 phương pháp này không loại trừ lẫn nhau, có thể áp dụng 2-3 phương pháp cùng lúc. Dưới đây chúng tôi phân tích sâu hơn về bảo mật, chức năng và thông lượng của các giao thức này.
Đầu tiên là PoS và hầu như tất cả các giao thức PoS đều giới thiệu tiền đề bảo mật mới. Lấy Algorand làm ví dụ, nó yêu cầu rằng hầu hết những người dùng trung thực khác có thể nhận được tin nhắn được gửi bởi hầu hết những người dùng trung thực khác trong một khoảng thời gian xác định. Điều này có nghĩa là khi bạn giữ Mã thông báo Algorand, theo thiết kế ban đầu của giao thức, bạn cần phải luôn trực tuyến để nhận tin nhắn. Nếu bạn không trực tuyến, bạn không phải là chủ sở hữu Mã thông báo đủ điều kiện.
Giao thức đồng thuận của Cardano, Ouroboros, giả định rằng tất cả người dùng có đồng hồ được đồng bộ hóa yếu và tất cả các tin nhắn có thể được gửi trong một khoảng thời gian nhất định. Điều này thực sự làm cho một giả định rất mạnh mẽ. Có nhiều cuộc tấn công có thể làm sai lệch đồng hồ trên giàn khai thác, nút công khai hoặc điện thoại của bạn. Và giải pháp này rất khó thực hiện trong môi trường thực tế.
Ngoài ra, Sleepy Protocol cũng yêu cầu người dùng phải có đồng hồ được đồng bộ hóa gần đúng.
Khi các giả định bảo mật này bị vi phạm, nó có thể gây ra hậu quả tai hại cho các giao thức PoS này. Và giao thức PoS giới thiệu một số phương thức tấn công mới, chẳng hạn như Tấn công không có gì, Tấn công nghiền nát, Tấn công tầm xa, những phương thức tấn công này không tồn tại trong giao thức PoW và tôi sẽ không mô tả chi tiết các phương thức tấn công này ở đây.
Vậy còn giao thức DAG thì sao?
Tất cả các giao thức DAG đều có vấn đề về thứ tự giao dịch. Nếu các khối được tạo đồng bộ như trong giao thức DAG, thì các công cụ khai thác khác nhau hoặc các nút công khai khác nhau sẽ có những phán đoán không nhất quán về thứ tự giao dịch: Tôi nghĩ rằng một số giao dịch được xác nhận, nhưng những giao dịch khác Con người có thể xem xét khác tập hợp các giao dịch được xác nhận. Lúc này, bạn sẽ có hai hướng suy nghĩ để giải quyết vấn đề.
Một là sắp xếp các giao dịch sau khi hoàn thành sắp xếp cấu trúc liên kết của chuỗi khối, điều đó có nghĩa là bạn cần đợi một thời gian dài để xác nhận giao dịch.
Hai là không xác nhận thứ tự giao dịch. Đầu vào của hợp đồng yêu cầu trình tự giao dịch toàn cầu. Nếu trình tự giao dịch được đánh giá bởi các công cụ khai thác khác nhau là khác nhau, thì mỗi công cụ khai thác có cách hiểu khác nhau về trình tự thực thi logic hợp đồng, đặc biệt là đối với các hợp đồng phức tạp. Điều này sẽ hạn chế chức năng của hợp đồng, các hợp đồng phức tạp không thể được thực thi và Mã thông báo có trong hợp đồng sẽ bị kẹt trong hợp đồng.
Còn những giao thức có hai loại khối thì sao? Giao thức loại hai khối, như tên cho thấy, sử dụng một khối khóa (Khối khóa) giống như khối trong NC để đảm bảo tính bảo mật của xác nhận giao dịch và phát các khối vi mô giữa hai khối khóa (Khối vi mô) để cải thiện thông lượng.
Các giao thức này thường có độ trễ xác nhận dài như giao thức DAG. Bitcoin NG áp dụng sơ đồ trên. Trong bài báo Bitcoin NG đã nêu rõ rằng nếu người dùng cần đảm bảo xác nhận giao dịch, thì trong Bitcoin NG, họ cần đợi xác nhận của một số khối chính và chịu đựng sự chậm trễ giao dịch kéo dài.
(Trong quá trình chia sẻ, Zhang Ren có đề cập rằng Byzcoin cũng gặp vấn đề tương tự. Tuy nhiên, sau khi phân tích kỹ hơn, vấn đề không giống như vậy. Nếu bạn quan tâm đến Byzcoin, bạn có thể vào diễn đàn:https://talk.nervos.org/t/ner...tiêu đề phụ
Yêu cầu TPS?
Tất cả các dự án áp dụng các giao thức đồng thuận thay thế này đều tuyên bố rằng chúng có thông lượng cao, vậy thông lượng của các dự án này là bao nhiêu? (Đoạn sau mời xem video, lúc khoảng 15h30 cảnh rất náo nhiệt)
Solana tuyên bố có thể xử lý 710.000 giao dịch mỗi giây. Nếu bạn có thể tạo ra bước đột phá lớn như vậy, bạn xứng đáng nhận được giải thưởng Turing. Tôi nóng lòng muốn nghe về giải thưởng của họ.
Ngoài ra còn có giao thức này tên là NKN, họ tuyên bố rằng họ có thể xử lý 1 triệu giao dịch mỗi giây trong khi có 10.000 nút trong toàn mạng, tôi không biết họ làm như thế nào nhưng tôi rất ấn tượng với cách họ đạt được nó tò mò.
Tôi cũng tò mò tại sao Stellar và Ripple cũng phân loại các giao thức của họ là NC và tôi cũng rất tò mò về cách 10.000 nút có thể xử lý 1 triệu giao dịch mỗi giây.
Và nếu bạn sắp có một giấc mơ, tốt hơn hết bạn nên có một giấc mơ lớn, như thỏa thuận này. Nó tuyên bố có thể có 10000000000000TPS với thời gian xác nhận cuối cùng chưa đến 1 giây.
Chà, tôi thực sự nghĩ rằng trái đất không đủ lớn đối với họ, họ thực sự cần tìm một Odaily khác lớn hơn để triển khai giao thức của họ.
Chúng ta nên lưu ý rằng TPS tự xưng là không thể so sánh được. Bởi vì chúng được mô phỏng trong các môi trường mạng khác nhau, một số mô phỏng thậm chí còn sử dụng băng thông 1Gbit/s, điều này rõ ràng là khác xa so với tình hình mạng thực.
Và những thỏa thuận này bỏ qua tình hình thực tế. Không ai trong số họ cho phép đồng bộ hóa các giao dịch. Đối với họ, dường như tất cả các giao dịch đã được đồng bộ hóa trong khối và giao thức đồng thuận chỉ được sử dụng để sắp xếp các giao dịch. Và một số mô phỏng giả định rằng có một kết nối trực tiếp giữa các thành viên ủy ban (các nút), nhưng thực tế là tất cả các thông báo trong mạng chuỗi công cộng đều được thực hiện bằng cách phát sóng và các thông báo phát sóng sẽ chiếm băng thông của các nút công khai.
tiêu đề phụ
Mô hình đơn giản để so sánh thông lượng
Ở đây chúng tôi có một mô hình để đánh giá TPS. Như thể hiện trong hình, trước hết, chúng tôi tin rằng băng thông của tất cả các nút công khai đều có giới hạn trên, tối đa 100% băng thông có thể được sử dụng và bạn không thể sử dụng hơn 100% băng thông. Có ba thành phần để sử dụng băng thông ở đây.
Như thể hiện trong hình trên, phần đầu tiên là tỷ lệ chiếm dụng băng thông của các giao dịch được sử dụng để xác nhận cuối cùng đồng bộ và phần này là TPS thực (Đây là TPS thực). Trước tiên, giao dịch phải được đồng bộ hóa trước khi giao dịch có thể được xác nhận. Phần thứ hai là phần băng thông bị "lãng phí" bởi giao thức đồng thuận. Phần thứ ba là băng thông chưa sử dụng.
Vì vậy, nếu bạn muốn cải thiện TPS, bạn chỉ có thể làm hai việc.
1. Giảm tỷ lệ chiếm dụng băng thông của giao thức đồng thuận
2. Giảm tỷ lệ băng thông không sử dụng
Chỉ có hai điều này có thể được thực hiện, vâng, không có cách nào khác và việc chiếm dụng băng thông giao thức của Lớp 1 không thể vượt quá 100%.
Sau đó, chúng ta hãy xem việc sử dụng băng thông của các giao thức đồng thuận thay thế khác.
Trên thực tế, nhiều giao thức lãng phí tài nguyên băng thông quý giá của chúng để liên lạc giữa các thành viên ủy ban.
Algorand lưu trữ chứng chỉ khối để chứng minh với người dùng mới rằng một khối đã được cam kết. Kích thước của mỗi chứng chỉ khối là 300KB, không phụ thuộc vào giới hạn kích thước khối. Nếu bạn tính theo kích thước khối là 1 MB, thì điều này có nghĩa là khoảng 25% băng thông sẽ luôn được sử dụng để đồng bộ hóa các chứng chỉ này. Vì vậy, tôi rất tò mò tại sao họ lại tuyên bố rằng thông lượng của họ tốt hơn NC, điều này chẳng có nghĩa lý gì cả.
Một cách khác để lãng phí băng thông trong các giao thức đồng thuận là các giao dịch dư thừa trong DAG khối và khối mồ côi. Như đã đề cập trong bài báo ở trên, nếu tất cả các nút chọn bao gồm cùng một tập hợp các giao dịch phụ trong khối, thì bất kỳ hai khối nào được tạo song song có thể xung đột và thông lượng sẽ không cao lắm.
tiêu đề phụ
Làm thế nào để vượt qua tình thế tiến thoái lưỡng nan của sự đồng thuận Satoshi Nakamoto?
Từ những phân tích trên, rõ ràng thông lượng hiện tại không thể làm chúng ta hài lòng, vì vậy giao thức đồng thuận NC-Max của Nervos CKB đã có một số cải tiến cho NC:
NC-Max có ba cải tiến chính
Sử dụng xác nhận giao dịch hai bước để giảm tỷ lệ khối mồ côi
Tự động điều chỉnh khoảng thời gian khối và phần thưởng khối để cải thiện tốt hơn việc sử dụng băng thông
Xem xét tất cả các khối trong chu kỳ khi điều chỉnh độ khó để chống lại các cuộc tấn công khai thác ích kỷ.
Tôi sẽ giải thích chi tiết tiếp theo.
NC có giới hạn thông lượng tự nhiên, bởi vì chỉ có hai điều bạn có thể làm để tăng thông lượng trong NC:
Điều đầu tiên là các khối lớn hơn, như Bitcoin Unlimited và Bitcoin Cash, và nhiều dự án khác cũng làm như vậy;
Thứ hai là giảm khoảng thời gian khối.
Tuy nhiên, vì việc phát khối cần có thời gian, nếu các nút khác phát hiện ra khối và phát nó trong quá trình phát, nó sẽ cạnh tranh với khối đang được phát và một trong số chúng sẽ trở thành khối mồ côi. Các khối lớn hơn sẽ mất nhiều thời gian hơn để phát và việc giảm khoảng thời gian khối thực sự làm giảm độ khó của việc tạo khối, giúp các nút khám phá khối dễ dàng hơn. Kết quả của hai kế hoạch này là tỷ lệ khối mồ côi trở nên cao hơn. Các khối mồ côi này chiếm nhiều băng thông hơn, nhưng chúng không góp phần xác nhận giao dịch. Khi tỷ lệ khối mồ côi tăng lên, tính bảo mật của hệ thống giảm và thông lượng giảm. Do đó, hai sơ đồ này cuối cùng sẽ đạt được sự cân bằng. Khi kích thước khối hoặc khoảng thời gian khối được điều chỉnh đến một mức nhất định, tỷ lệ khối mồ côi sẽ cao ở một mức độ nhất định. Ngay cả khi bạn tăng thêm kích thước khối hoặc giảm khoảng thời gian khối , thông lượng Cũng sẽ không được cải thiện.
Tại sao có quá nhiều khối mồ côi sẽ ảnh hưởng tiêu cực đến bảo mật và hiệu suất của mạng? Trong hình trên, chúng ta có thể thấy rằng khi tỷ lệ khối mồ côi rất cao, kẻ tấn công có thể dễ dàng xây dựng một chuỗi dài hơn một cách riêng tư. Kẻ tấn công chỉ cần có sức mạnh tính toán thấp hơn nhiều so với 51% tổng sức mạnh tính toán của mạng để ghi đè lên chuỗi khối. Và các khối mồ côi sẽ tiêu tốn một lượng lớn băng thông của các nút công khai, điều này sẽ có tác động tiêu cực lớn đến thông lượng của toàn bộ hệ thống.
Vậy làm cách nào để phá vỡ giới hạn thông lượng NC? Sau khi phân tích ở trên, nếu chúng ta muốn phá vỡ giới hạn này, chúng ta phải giảm tỷ lệ khối mồ côi. Nếu tỷ lệ khối mồ côi giảm xuống, cả tính bảo mật và thông lượng của mạng đều có thể được cải thiện.
Làm thế nào để giảm tỷ lệ khối mồ côi? Sự xuất hiện của các khối mồ côi là do sự chậm trễ của việc phát khối. Nếu một khối khác được phát hiện trong quá trình phát một khối, một trong các khối sẽ trở thành khối mồ côi. Nếu việc phát khối có thể được hoàn thành ngay lập tức, thì đương nhiên sẽ không có khối mồ côi nào. Vậy làm cách nào để chúng tôi đảm bảo rằng các khối được phát đủ nhanh?
Các nhà phát triển bitcoin đã đầu tư rất nhiều tài nguyên và năng lượng để tăng tốc độ phát sóng của các khối và chúng tôi cần tìm hiểu thêm xem khối nào phát chậm hoặc gặp sự cố.
Hãy xem chi tiết điều này xảy ra như thế nào, xem hình ảnh bên dưới.
Trong mạng Bitcoin hiện tại, nếu mọi việc suôn sẻ, một khối sẽ được phát thông qua giao thức chuyển tiếp Khối nhỏ gọn.
Trong Khối nhỏ gọn, toàn bộ giao dịch (khoảng 250 Byte cho mỗi giao dịch bằng Bitcoin) không được phát rộng, nhưng ID giao dịch trong Khối nhỏ gọn được phát rộng. Các ID giao dịch này tạo thành một Khối nhỏ gọn, nhỏ hơn nhiều so với khối thực tế, do đó tốc độ sẽ nhanh hơn nhiều.
Khi nút A quảng bá Khối thu gọn tới nút B, nút B sẽ kiểm tra các ID giao dịch này. Các khối nhỏ gọn. Chặn các nút liền kề, tình hình này rất tốt, quá trình này rất suôn sẻ.
Tuy nhiên, nếu có Giao dịch mới trong Khối nhỏ gọn, nút B trước tiên sẽ cần đồng bộ hóa Giao dịch mới từ nút A, sau đó xác minh chữ ký của các giao dịch này.Các bước này rất tốn thời gian. Nút B chỉ có thể tiếp tục phát khối sau khi toàn bộ khối đã được xác minh là chính xác. Quá trình này ngăn không cho khối nhận được là bất hợp pháp, do đó các công cụ khai thác sẽ khai thác và phát sóng sau khối này. Nếu nó không được xác minh và phát hiện là khối bất hợp pháp thì các khối sau khối bất hợp pháp này sẽ không hợp lệ. Quá trình đồng bộ hóa Giao dịch mới là lý do chính dẫn đến sự chậm trễ của việc phát khối Bitcoin.
Vì vậy, Ethereum là một nỗ lực kém cỏi, hãy để tôi phân tích xem họ đã làm điều đó như thế nào. Ethereum chỉ đơn giản là rút ngắn khoảng thời gian giữa các khối, nhưng Ethereum có một vấn đề là nó không thể xác minh tính hợp lệ của các giao dịch trước khi nhận được một khối. Vì tính hợp lệ của một giao dịch trong Ethereum phụ thuộc vào thứ tự của các giao dịch trong khối, nên nếu bạn muốn xác minh tính hợp lệ của giao dịch, bạn phải đợi cho đến khi nhận được toàn bộ khối, để mỗi khối thực sự là mới. Giao dịch.
Và giao thức mạng của Ethereum được bảo trì rất kém và không có sự lặp lại nào kể từ năm 2015.
Và cũng có rất nhiều dự phòng trong quá trình phát sóng giao dịch. Ứng dụng khách Ethereum sẽ phát cùng một giao dịch 7 lần tới các nút khác nhau, điều đó có nghĩa là mỗi nút sẽ nhận được cùng một giao dịch 7 lần. (Ethereum có các ứng dụng khách khác nhau, chẳng hạn như Parity Ethereum, Geth, v.v.) Và có sự không nhất quán giữa các loại ứng dụng khách khác nhau và hai ứng dụng khách Ethereum chính về cơ bản là độc lập.
Do đó, có rất ít nút có thể liên kết hai mạng khác nhau, đó là lý do tại sao tỷ lệ khối mồ côi của Ethereum đôi khi cao tới 30% và thông lượng giao dịch rất thấp.
Và các công ty khai thác lớn không có động cơ để tăng tốc độ phát sóng khối. Bởi vì nếu các khối của tôi có thể được phát chậm hơn, điều đó có nghĩa là tôi thực sự có thể đạt được "khai thác ích kỷ" (ở đây, các công cụ khai thác lớn không giữ lại các khối, nhưng quá trình phát khối chậm hơn và các công cụ khai thác khác xuất hiện trong quá trình này. Các khối cạnh tranh, và bởi vì tôi là một người khai thác lớn, tôi có xác suất chiến thắng cao hơn trong quá trình cạnh tranh với các khối cạnh tranh khác). Đây là một điều tốt cho tôi, tại sao tôi phải tăng tốc độ phát sóng khối?
Phần thưởng khối chú trong Ethereum cũng không giúp được gì, vì những người khai thác vẫn được thưởng cho các khối mồ côi. Do đó, những người khai thác nhỏ sẽ áp dụng phương pháp phát tiêu đề khối và khối trống trước, vì tốc độ phát tiêu đề khối sẽ nhanh hơn nhiều. Và vì họ không biết giao dịch nào sẽ được đưa vào khối tiếp theo, nên những người khai thác thường khai thác một khối trống để đảm bảo rằng khối đó không chứa các giao dịch xung đột với các giao dịch của khối trước đó. Điều này rất tệ vì các khối trống không góp phần xác nhận giao dịch.
Dưới đây là thiết kế của chúng tôi để giảm bớt một số vấn đề được đề cập ở trên.
Hình ảnh này là cấu trúc khối, chúng tôi đã thêm một số trường trên cơ sở cấu trúc khối Bitcoin.
Hình trên là cấu trúc khối của khối hoàn chỉnh của chúng tôi. Đầu tiên chúng ta có một khu vực đề xuất giao dịch (khu vực màu xanh mòng két). Chỉ khu vực đề xuất giao dịch mới có thể chứa Giao dịch mới, trong khi khu vực xác nhận giao dịch truyền thống (khu vực màu cam) chỉ có thể chứa các giao dịch trong khu vực đề xuất giao dịch của một số khối trước đó. hn chặn Giao dịch trong khu vực đề xuất giao dịch của . Chỉ những giao dịch này mới có thể được xác nhận, Giao dịch mới không thể được xác nhận bởi khu vực xác nhận giao dịch. Khu vực đề xuất giao dịch không chứa các giao dịch hoàn chỉnh, chỉ có ID giao dịch (ID giao dịch bị rút ngắn), vì vậy khu vực đề xuất giao dịch sẽ rất nhỏ.
Bất kỳ số lượng khối chú nào (vùng màu tím) đều có thể được chứa trong khu vực tiêu đề khối chú và các khối chú phải chứa tiêu đề khối và khu vực đề xuất giao dịch của chúng. Khu vực tiêu đề khối chú không được tính vào kích thước khối, do đó, nó không bị giới hạn bởi kích thước khối, vì vậy những người khai thác sẽ không bị hạn chế thêm các khối chú.
Hãy để tôi giải thích thêm về khu vực đề xuất giao dịch. Khu vực này rất nhỏ vì nó chỉ chứa ID giao dịch. Giao dịch hoàn chỉnh được phát đồng bộ với khối, bởi vì đây là một quá trình song song, do đó, việc phát của giao dịch sẽ không ảnh hưởng đến việc phát của khối. Và nút chỉ cần xác minh hàm băm sau khi nhận được giao dịch được phát sóng, điều này sẽ không ảnh hưởng đến quá trình xác minh của khối.
Mặc dù điều này có nghĩa là có thể có giao dịch không hợp lệ trong khu vực đề xuất giao dịch, giao dịch chi tiêu gấp đôi và giao dịch mà người khai thác có thể không chấp nhận, nhưng điều đó không thành vấn đề.
Tương tự như quy trình phát khối Bitcoin đã đề cập ở trên, trong giao thức của chúng tôi, nút phát hiện ra khối trước tiên sẽ phát Khối nhỏ gọn (nghĩa là tiêu đề khối và ID của giao dịch). Khối nhỏ gọn lớn hơn một chút so với Bitcoin, bao gồm Khu vực đề xuất giao dịch và tiêu đề khối của một số khối chú và khu vực đề xuất giao dịch của các khối chú. Tuy nhiên, vì bản thân Khối nhỏ gọn đủ nhỏ nên nó thường được quảng bá tới các nút lân cận ngay lập tức.
Nếu một số giao dịch mới được đề xuất không có trong nhóm giao dịch của nút, chúng sẽ được phát sau khi phát hành Khối nhỏ gọn. Đây là các quá trình song song và không ảnh hưởng lẫn nhau. Nút nhận giao dịch và phát nó đến các nút lân cận sau khi xác minh hàm băm.
Điều này tự nhiên đặt ra một số câu hỏi:
Điều gì xảy ra nếu người khai thác từ chối cung cấp phiên bản đầy đủ của giao dịch được đề xuất?
Tôi đã đặt thỏa thuận này trong phần đề xuất thỏa thuận của mình, nhưng khi bạn hỏi tôi về thỏa thuận đầy đủ, tôi giả vờ không biết.
Trên thực tế, điều này sẽ không ảnh hưởng đến việc phát khối, bởi vì khối có thể được phát bất kể có Giao dịch mới trong khu vực đề xuất giao dịch hay không.
Và những người khai thác khác sẽ tiếp tục khai thác vì luôn có đủ các giao dịch được đề xuất để xác nhận. Người khai thác không cần phải đào khối, vì khu vực đề xuất giao dịch của khối trước đó chứa ID giao dịch mà nó sẽ đóng gói và các khối đã được phát hiện sẽ phát ID giao dịch trong khu vực xác nhận giao dịch được đóng gói trong khối nhỏ gọn. Người khai thác biết giao dịch nào được đóng gói và giao dịch nào không, và họ sẽ không chọn giao dịch xung đột với khu vực xác nhận giao dịch của khối được phát hiện. Do đó, người khai thác sẽ chọn tiếp tục đóng gói giao dịch để tạo khối và nhận phí để góp phần xác nhận giao dịch.
Vậy điều gì sẽ xảy ra nếu những người khai thác bao gồm các giao dịch được đề xuất nhưng chưa được phát sóng này trong các khối mới nhất của họ, để đạt được một loại lợi thế khai thác ích kỷ?
Trong NC của Bitcoin, những người khai thác có được lợi thế khai thác bằng cách làm chậm quá trình phát khối. Công cụ khai thác thường chỉ có thể phát tiêu đề khối khi khai thác một khối và chậm lại khi phát toàn bộ khối. Trong quá trình này, chỉ người khai thác mới có thể khai thác (vì chỉ người đó mới biết thông tin của khối tiếp theo và có thể khai thác dựa trên khối mới này, quá trình này tương tự như giữ lại các khối).
Nhưng trong giao thức của chúng tôi, việc áp dụng phương pháp này sẽ chỉ làm chậm tốc độ phát khối sau n khối. Bởi vì các giao dịch được đề xuất nhưng không được phát sóng chỉ được biết bởi những người khai thác ích kỷ và chỉ những người khai thác ích kỷ mới có thể sử dụng chúng để làm lợi cho họ. Tuy nhiên, điều này không thể được sử dụng trong khối tiếp theo, bởi vì trong giao thức của chúng tôi, chỉ có thể khai thác n khối trước khu vực đề xuất chứa các giao dịch và cần có một khoảng thời gian ở giữa.
Người khai thác chỉ có thể khai thác các giao dịch đề xuất trong các khối từ hm đến hn, nhưng không thể khai thác các giao dịch đề xuất trong khối trước đó, trừ khi kẻ tấn công cũng khai thác khối này.
Như được hiển thị, đây là sự so sánh giữa giao thức đồng thuận của chúng tôi và Bitcoin NC. Trong Bitcoin NC, khi một người khai thác ích kỷ tìm thấy khối h, nó có thể bắt đầu khai thác khối h+1 ngay lập tức và những người khai thác trung thực chỉ có thể bắt đầu khai thác sau khi nhận được khối h hoàn chỉnh, bởi vì những người khai thác khác cần biết Giao dịch hoàn chỉnh có trong khối là đã được xác minh để xác định rằng khối đó là hợp pháp và người khai thác ích kỷ có thể làm chậm tốc độ truyền của khối h để khiến những người khai thác khác nhận được khối sau. Trong thời gian phát sóng khối là khoảng thời gian thuận lợi cho những người khai thác ích kỷ.
Tuy nhiên, trong giao thức của chúng tôi, khi một người khai thác ích kỷ tìm thấy một khối h và phát một Khối nhỏ gọn chứa tiêu đề khối và ID giao dịch, thì người khai thác trung thực có thể bắt đầu khai thác h+1 ngay lập tức. Nếu người khai thác ích kỷ muốn tận dụng các giao dịch được đề xuất nhưng không được phát sóng này, thì sau đó, nó phải tìm khối n khối chứa các giao dịch được đề xuất nhưng chưa được phát sóng này để họ có thể tận dụng lợi thế này. Tuy nhiên, điều này khó xảy ra, bạn không thể chắc chắn rằng khối sau n khối được bạn khai thác, điều này rất khó dự đoán.
Để tận dụng băng thông tốt hơn, giao thức của chúng tôi sử dụng cơ chế điều chỉnh độ khó khác, đặt tỷ lệ khối mồ côi cố định (được tính dựa trên số lượng khối chú trong giai đoạn điều chỉnh độ khó trước đó).
Nếu tỷ lệ khối mồ côi thấp hơn tỷ lệ khối mồ côi đã đặt trong chu kỳ điều chỉnh độ khó trước đó, thì độ khó khai thác sẽ giảm, khoảng thời gian giữa các khối sẽ giảm và thông lượng sẽ tăng lên. Điều đó nói rằng, ít khối mồ côi hơn có nghĩa là trạng thái hiện tại của mạng thực sự có khả năng đồng bộ hóa các giao dịch nhanh hơn và chúng tôi có thể tăng thông lượng mà không ảnh hưởng đến tính phi tập trung của mạng.
Ngược lại, nếu độ khó tăng lên, khoảng cách giữa các khối sẽ tăng lên và thông lượng sẽ giảm xuống. Nếu tỷ lệ khối mồ côi cao, điều đó có nghĩa là mạng hiện tại không thể xử lý nhiều giao dịch như vậy trong giai đoạn điều chỉnh độ khó này và giao thức sẽ giảm thông lượng.
Đồng thời, phần thưởng khối sẽ tỷ lệ với 1/(khoảng thời gian khối dự kiến), do đó, tổng phần thưởng khối dự kiến trong mỗi chu kỳ điều chỉnh độ khó là cố định.
Điều này có nghĩa là giả sử chúng tôi tạo ra một khối cứ sau mười phút, thì sẽ có 12,5 bitcoin trong mỗi khối và nếu việc điều chỉnh độ khó thay đổi thành một khối cứ sau 5 phút, thì sẽ có 6,125 bitcoin trong mỗi khối. Do đó, tỷ giá phát hành tiền tệ cũng được giữ cố định.
Cuối cùng, chống lại các cuộc tấn công khai thác ích kỷ. Chúng tôi đã đề cập trước đó rằng sự khác biệt giữa giao thức của chúng tôi và NC là cơ chế điều chỉnh độ khó của chúng tôi được tính toán dựa trên tất cả các khối xuất hiện trong khoảng thời gian điều chỉnh độ khó và các khối chú thích cũng được đưa vào khi ước tính tổng sức mạnh tính toán.
Trong NC-Max, giả định rằng kẻ tấn công chiếm 30% tổng sức mạnh tính toán và những người khai thác trung thực chiếm 70%.Nếu không có cuộc tấn công khai thác ích kỷ, kẻ tấn công có thể tìm thấy 3 khối trong số 10 khối và những người khai thác trung thực có thể tìm thấy 7 khối. Nếu khai thác ích kỷ được thực hiện, kẻ tấn công có thể tìm thấy 3 khối trong số 7 khối, những người khai thác trung thực tìm thấy 4 khối, 3 khối trung thực sẽ trở thành khối mồ côi và chuỗi chính sẽ phát triển chậm.
Như đã đề cập trước đó, khai thác ích kỷ không có lợi trong chu kỳ điều chỉnh độ khó đầu tiên, vậy điều gì sẽ xảy ra trong chu kỳ điều chỉnh độ khó thứ hai?
Trong chu kỳ điều chỉnh độ khó tiếp theo, độ khó sẽ không thay đổi (vì độ khó sẽ được tính toán dựa trên tất cả các khối, kể cả các khối mồ côi) và kẻ tấn công không thể sử dụng cùng một sức mạnh tính toán để tìm thêm khối, vì vậy việc khai thác ích kỷ không còn sinh lãi hình ảnh.
Điều đó có nghĩa là, chúng tôi giả định rằng giá tiền tệ vẫn ổn định trong một khoảng thời gian ngắn. Vì những kẻ tấn công khai thác ích kỷ thiển cận nên phần thưởng của chúng được xác định theo phần thưởng thu được trên mỗi đơn vị thời gian, có thể tương đương với cùng một sức mạnh tiêu dùng.giải thưởng. Trong Bitcoin, những kẻ tấn công khai thác ích kỷ có thể "buộc" giao thức giảm độ khó của việc tạo khối bằng cách giảm tốc độ tăng trưởng của chuỗi, để chúng có thể nhận được nhiều phần thưởng hơn trên mỗi đơn vị thời gian sau khi điều chỉnh độ khó. Trong thiết kế của giao thức NC-Max, độ khó tạo khối sẽ được tính toán dựa trên tất cả các khối, bao gồm cả khối mồ côi, kẻ tấn công biến khối của những người khai thác trung thực thành khối mồ côi, nhưng không thể "ép" giao thức giảm độ khó của việc tạo khối. Nhận phần thưởng cao hơn trên mỗi đơn vị thời gian.
Cuối cùng, để tóm tắt, giao thức của chúng tôi sẽ sử dụng tốt các khối mồ côi:
Chúng tôi hy vọng sẽ giảm số lượng khối mồ côi thông qua xác minh giao dịch hai bước. Sau khi số lượng khối mồ côi giảm xuống, chúng tôi sử dụng tỷ lệ khối mồ côi làm chỉ số sử dụng băng thông để tự động điều chỉnh thông lượng.
Và thông tin về khối mồ côi được ghi trong chuỗi khối, chúng tôi sử dụng thông tin này trong thuật toán điều chỉnh độ khó khai thác để làm cho việc khai thác ích kỷ trở nên không có lợi.
NC-Max là giao thức đồng thuận PoW của Nervos CKB. NC là tên viết tắt của Nakamoto Consensus, là giao thức đồng thuận của Bitcoin. Nếu sau khi đọc bài viết này, bạn nghĩ rằng giao thức đồng thuận này nên có một cái tên hay hơn, vui lòng cho chúng tôi biết.
Nên đọc: Bài báo Phân tích An toàn Đồng thuận của Tiến sĩ Zhang Ren"Phát triển các tiêu chí chung: Đánh giá tính bảo mật của các giao thức đồng thuận PoW"
