Sự cân nhắc về khả năng mở rộng: Thách thức của Polkadot và Web3
Trong bối cảnh công nghệ blockchain đang hướng tới hiệu quả cao hơn, một vấn đề then chốt dần hiện rõ: Làm thế nào để mở rộng hiệu suất mà không hy sinh tính an toàn và tính linh hoạt của hệ thống? Đây không chỉ là thách thức ở cấp độ kỹ thuật, mà còn là sự lựa chọn sâu sắc trong thiết kế kiến trúc. Đối với hệ sinh thái Web3, một hệ thống nhanh hơn nếu được xây dựng trên nền tảng hy sinh lòng tin và tính an toàn thường khó có thể hỗ trợ đổi mới bền vững thực sự.
Là một trong những động lực quan trọng cho khả năng mở rộng Web3, Polkadot có phải đã hy sinh một số điều dưới mục tiêu cao về thông lượng và độ trễ thấp không? Mô hình rollup của nó có phải đã nhượng bộ về phân quyền, an ninh hoặc khả năng tương tác mạng không?
Bài viết này sẽ xoay quanh những vấn đề này, phân tích sâu sắc những sự lựa chọn và thỏa hiệp trong thiết kế khả năng mở rộng của Polkadot, đồng thời so sánh với các giải pháp của những chuỗi công khai chính khác, khám phá những lựa chọn khác nhau của chúng trong ba yếu tố: hiệu suất, an ninh và phi tập trung.
Những thách thức trong thiết kế mở rộng Polkadot
Sự cân bằng giữa tính linh hoạt và phi tập trung
Kiến trúc của Polkadot phụ thuộc vào mạng xác thực và chuỗi trung gian, điều này có thể mang lại rủi ro tập trung trong một số khía cạnh không? Có khả năng hình thành điểm lỗi đơn lẻ hoặc kiểm soát, từ đó ảnh hưởng đến đặc điểm phi tập trung của nó không?
Việc chạy Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian, giao tiếp của nó sử dụng cơ chế giao thức collator. Giao thức này hoàn toàn không cần cấp phép, không cần tin tưởng, bất kỳ ai có kết nối mạng đều có thể sử dụng nó, kết nối với một lượng nhỏ các nút chuỗi trung gian và gửi yêu cầu chuyển đổi trạng thái của rollup. Những yêu cầu này sẽ được xác minh bởi một core nào đó của chuỗi trung gian, chỉ cần thỏa mãn một điều kiện: phải là chuyển đổi trạng thái hợp lệ, nếu không trạng thái của rollup sẽ không được tiến lên.
Sự đánh đổi của mở rộng theo chiều dọc
Rollup có thể đạt được khả năng mở rộng theo chiều dọc bằng cách tận dụng kiến trúc đa lõi của Polkadot. Khả năng mới này được giới thiệu thông qua tính năng "mở rộng linh hoạt". Trong quá trình thiết kế, đã phát hiện ra rằng, vì việc xác minh khối rollup không cố định thực hiện trên một lõi nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Vì giao thức gửi khối đến chuỗi trung gian là không cần giấy phép và không cần tin tưởng, bất kỳ ai cũng có thể gửi khối để xác minh trên bất kỳ core nào được phân bổ cho rollup. Kẻ tấn công có thể lợi dụng điểm này, gửi lại các khối hợp pháp đã được xác minh trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó giảm tổng thể thông lượng và hiệu suất của rollup.
Mục tiêu của Polkadot là duy trì tính linh hoạt của rollup và hiệu quả sử dụng tài nguyên chuỗi trung gian mà không làm ảnh hưởng đến các đặc tính quan trọng của hệ thống.
Sequencer có đáng tin cậy không?
Một giải pháp đơn giản là thiết lập giao thức là "có giấy phép": ví dụ, áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng rằng bộ sắp xếp sẽ không có hành vi độc hại, từ đó đảm bảo tính khả thi của rollup.
Tuy nhiên, trong triết lý thiết kế của Polkadot, chúng ta không thể có bất kỳ giả định nào về độ tin cậy của sequencer, vì để duy trì các đặc tính "không cần tin cậy" và "không cần cấp phép" của hệ thống. Bất kỳ ai cũng nên có thể sử dụng giao thức collator để gửi yêu cầu chuyển trạng thái rollup.
Polkadot: Giải pháp không thỏa hiệp
Giải pháp cuối cùng mà Polkadot chọn là: giao hoàn toàn vấn đề cho hàm chuyển trạng thái của rollup (Runtime) để giải quyết. Runtime là nguồn đáng tin cậy duy nhất cho tất cả thông tin đồng thuận, vì vậy phải tuyên bố rõ ràng trong đầu ra rằng nên thực hiện xác minh trên core Polkadot nào.
Thiết kế này đảm bảo cả tính linh hoạt và an ninh. Polkadot sẽ thực hiện lại các chuyển trạng thái của rollup trong quy trình khả dụng và đảm bảo tính chính xác của phân bổ core thông qua giao thức kinh tế mã hóa ELVES.
Trước khi ghi dữ liệu vào lớp khả dụng của Polkadot trong bất kỳ khối rollup nào, một nhóm khoảng 5 người xác thực sẽ xác minh tính hợp pháp của nó. Họ nhận các biên lai ứng cử và chứng minh tính hợp lệ được gửi bởi bộ sắp xếp, trong đó bao gồm khối rollup và chứng minh lưu trữ tương ứng. Những thông tin này sẽ được chuyển cho hàm xác thực của chuỗi song song xử lý, và sẽ được thực hiện lại bởi các xác thực trên chuỗi tiếp hợp.
Kết quả xác minh bao gồm một bộ chọn lõi, được sử dụng để chỉ định xác minh khối trên lõi nào. Người xác minh sẽ so sánh chỉ số đó với lõi mà mình chịu trách nhiệm; nếu không khớp, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo rằng hệ thống luôn giữ được các thuộc tính không cần tin cậy và không cần cấp phép, tránh hành vi thao túng vị trí xác minh của những kẻ xấu như trình sắp xếp, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core, nó vẫn giữ được tính linh hoạt.
An toàn
Trong quá trình theo đuổi khả năng mở rộng, Polkadot không hề thỏa hiệp về mặt an toàn. An ninh của rollup được đảm bảo bởi chuỗi trung gian, chỉ cần một bộ sắp xếp trung thực là có thể duy trì sự sống.
Thông qua giao thức ELVES, Polkadot mở rộng tính bảo mật của mình hoàn toàn đến tất cả các rollup, xác minh tất cả các phép toán trên core mà không cần phải hạn chế hoặc giả định về số lượng core được sử dụng.
Do đó, rollup của Polkadot có thể đạt được sự mở rộng thực sự mà không hy sinh tính bảo mật.
Độ phổ quát
Mở rộng linh hoạt sẽ không giới hạn tính lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện các tính toán Turing đầy đủ trong môi trường WebAssembly, miễn là mỗi lần thực hiện hoàn thành trong vòng 2 giây. Nhờ vào mở rộng linh hoạt, tổng khối lượng tính toán có thể thực hiện trong mỗi chu kỳ 6 giây được cải thiện, nhưng loại hình tính toán không bị ảnh hưởng.
Độ phức tạp
Thông lượng cao hơn và độ trễ thấp hơn sẽ không thể tránh khỏi việc đưa ra sự phức tạp, đây là cách duy nhất để chấp nhận trong thiết kế hệ thống.
Rollup có thể điều chỉnh tài nguyên một cách động thông qua giao diện Agile Coretime để duy trì mức độ an toàn đồng nhất. Chúng cũng cần thực hiện một phần yêu cầu RFC103 để phù hợp với các tình huống sử dụng khác nhau.
Sự phức tạp cụ thể phụ thuộc vào chiến lược quản lý tài nguyên của rollup, các chiến lược này có thể dựa vào các biến trên chuỗi hoặc ngoài chuỗi. Ví dụ:
Chiến lược đơn giản: Luôn sử dụng một số lượng core cố định, hoặc điều chỉnh thủ công bên ngoài.
Chiến lược nhẹ: Giám sát tải giao dịch cụ thể trong mempool của nút;
Chiến lược tự động hóa: Gọi dịch vụ coretime trước bằng cách sử dụng dữ liệu lịch sử và giao diện XCM để cấu hình tài nguyên.
Mặc dù cách thức tự động hóa hiệu quả hơn, nhưng chi phí thực hiện và kiểm tra cũng tăng đáng kể.
khả năng tương tác
Polkadot hỗ trợ khả năng tương tác giữa các rollup khác nhau, trong khi khả năng mở rộng linh hoạt không ảnh hưởng đến lưu lượng tin nhắn.
Giao tiếp tin nhắn giữa các rollup được thực hiện bởi lớp truyền tải dưới, không gian khối giao tiếp của mỗi rollup là cố định, không liên quan đến số lượng lõi được phân bổ.
Trong tương lai, Polkadot cũng sẽ hỗ trợ truyền tin ngoài chuỗi, với chuỗi trung gian đóng vai trò là mặt kiểm soát, thay vì mặt dữ liệu. Cập nhật này sẽ nâng cao khả năng giao tiếp giữa các rollup cùng với khả năng mở rộng linh hoạt, từ đó tăng cường khả năng mở rộng theo chiều dọc của hệ thống.
Các giao thức khác đã đưa ra những thỏa hiệp nào?
Như mọi người đều biết, việc nâng cao hiệu suất thường phải hy sinh sự phi tập trung và an toàn. Nhưng từ góc độ hệ số Nakamoto, ngay cả khi một số đối thủ của Polkadot có mức độ phi tập trung thấp, hiệu suất của chúng cũng không được như mong đợi.
Solana
Solana không sử dụng kiến trúc phân đoạn của Polkadot hay Ethereum, mà thay vào đó thực hiện khả năng mở rộng bằng kiến trúc đơn lớp với hiệu suất cao, dựa vào chứng minh lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, với TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lập lịch lãnh đạo được công khai trước và có thể xác minh.
Vào đầu mỗi epoch (khoảng hai ngày hoặc 432.000 slot), các slot được phân bổ theo lượng staked;
Càng nhiều stake, càng nhiều phân bổ. Ví dụ, một người xác thực stake 1% sẽ có khoảng 1% cơ hội tạo khối;
Tất cả các thợ mỏ đều được công bố trước, làm tăng rủi ro mạng bị tấn công DDoS có định hướng và thường xuyên bị ngưng hoạt động.
PoH và xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung hóa của các nút xác thực. Nút càng nhiều staked thì cơ hội ra khối càng lớn, các nút nhỏ gần như không có slot, làm gia tăng thêm sự tập trung hóa, đồng thời cũng tăng nguy cơ hệ thống bị tê liệt sau khi bị tấn công.
Solana đã hy sinh khả năng phi tập trung và khả năng chống tấn công để theo đuổi TPS, hệ số Nakamoto của nó chỉ là 20, thấp hơn nhiều so với 172 của Polkadot.
TON
TON tuyên bố TPS có thể đạt 104.715, nhưng con số này được đạt được trên mạng thử nghiệm riêng, với 256 nút, trong điều kiện mạng và phần cứng lý tưởng. Trong khi đó, Polkadot đã đạt tới 128K TPS trên mạng công cộng phi tập trung.
Cơ chế đồng thuận của TON có những rủi ro về an ninh: danh tính của các nút xác thực phân đoạn sẽ bị lộ ra sớm. Bản trắng của TON cũng chỉ rõ rằng, mặc dù điều này có thể tối ưu hóa băng thông, nhưng cũng có thể bị khai thác xấu. Do thiếu cơ chế "phá sản của người đánh cược", kẻ tấn công có thể chờ đợi một phân đoạn hoàn toàn nằm trong sự kiểm soát của mình, hoặc thông qua cuộc tấn công DDoS để chặn những người xác thực trung thực, từ đó thay đổi trạng thái.
So với đó, các validator của Polkadot được phân bổ ngẫu nhiên và tiết lộ muộn, kẻ tấn công không thể biết trước danh tính của validator, cuộc tấn công phải đặt cược toàn bộ để thành công, chỉ cần có một validator trung thực khởi xướng tranh chấp, cuộc tấn công sẽ thất bại và dẫn đến tổn thất cho kẻ tấn công.
Avalanche
Avalanche sử dụng kiến trúc mạng chính + mạng con để mở rộng, mạng chính bao gồm X-Chain (chuyển tiền, ~4.500 TPS), C-Chain (hợp đồng thông minh, ~100-200 TPS), P-Chain (quản lý các xác nhận viên và mạng con).
Mỗi subnet lý thuyết có thể đạt TPS khoảng ~5,000, tương tự như tư tưởng của Polkadot: giảm tải cho từng shard để đạt được khả năng mở rộng. Nhưng Avalanche cho phép các validator tự do chọn tham gia vào subnet, và subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi sự phi tập trung và an toàn.
Tại Polkadot, tất cả các rollup đều chia sẻ bảo đảm an ninh thống nhất; trong khi đó, các subnet của Avalanche không có bảo đảm an ninh mặc định, một số thậm chí có thể hoàn toàn tập trung. Nếu muốn nâng cao an ninh, vẫn cần phải thỏa hiệp về hiệu suất và khó khăn trong việc cung cấp cam kết an ninh xác định.
Ethereum
Chiến lược mở rộng của Ethereum là đặt cược vào khả năng mở rộng của lớp rollup, thay vì giải quyết vấn đề trực tiếp ở lớp cơ sở. Cách tiếp cận này về bản chất không giải quyết vấn đề mà chỉ chuyển vấn đề lên lớp trên của ngăn xếp.
Optimistic Rollup
Hiện nay, hầu hết các Optimistic rollup đều là phi tập trung (thậm chí có những cái chỉ có một sequencer), tồn tại các vấn đề như thiếu an toàn, cách biệt lẫn nhau, độ trễ cao (cần phải chờ thời gian chứng minh gian lận, thường là vài ngày).
ZK Rollup
Việc triển khai ZK rollup bị giới hạn bởi khối lượng dữ liệu có thể xử lý cho một giao dịch. Nhu cầu tính toán để tạo ra bằng chứng không biết rất cao, và cơ chế "người chiến thắng nhận hết" dễ dẫn đến sự tập trung của hệ thống. Để đảm bảo TPS, ZK rollup thường giới hạn khối lượng giao dịch cho mỗi lô, và trong những thời điểm có nhu cầu cao sẽ gây ra tắc nghẽn mạng, giá gas tăng, ảnh hưởng đến trải nghiệm của người dùng.
So với đó, chi phí của ZK rollup hoàn toàn Turing là khoảng 2x10^6 lần so với giao thức an ninh kinh tế cốt lõi của Polkadot.
Ngoài ra, vấn đề khả năng sẵn có của dữ liệu ZK rollup cũng sẽ làm trầm trọng thêm những hạn chế của nó. Để đảm bảo bất kỳ ai cũng có thể xác minh giao dịch, vẫn cần cung cấp dữ liệu giao dịch đầy đủ. Điều này thường phụ thuộc vào các giải pháp khả năng sẵn có dữ liệu bổ sung, làm tăng thêm chi phí và phí tổn cho người dùng.
Kết luận
Cuối cùng của khả năng mở rộng, không nên là sự thỏa hiệp.
So với các chuỗi công khai khác, Polkadot không chọn con đường đánh đổi giữa tập trung hóa và hiệu suất, hay đánh đổi giữa niềm tin đã được thiết lập và hiệu quả, mà thay vào đó đạt được sự cân bằng đa chiều giữa tính bảo mật, phi tập trung và hiệu suất cao thông qua mở rộng linh hoạt, thiết kế giao thức không cần cấp phép, lớp bảo mật thống nhất và cơ chế quản lý tài nguyên linh hoạt.
Trong bối cảnh theo đuổi việc ứng dụng quy mô lớn hơn, "mở rộng không tin cậy" mà Polkadot kiên trì có lẽ mới thật sự là giải pháp hỗ trợ cho sự phát triển lâu dài của Web3.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
13 thích
Phần thưởng
13
10
Chia sẻ
Bình luận
0/400
DuskSurfer
· 07-24 17:29
Cơ sở hạ tầng trước tiên mới có thể tăng tốc.
Xem bản gốcTrả lời0
TokenRationEater
· 07-24 00:36
Vẫn chưa đủ nhanh, đã 22 năm rồi.
Xem bản gốcTrả lời0
LiquidityWhisperer
· 07-22 15:35
Tốc độ và an toàn không thể đều có sao?
Xem bản gốcTrả lời0
DiamondHands
· 07-22 13:17
Tốc độ và độ an toàn vốn dĩ đã mâu thuẫn nhau.
Xem bản gốcTrả lời0
GasGuru
· 07-21 22:12
Lại có chain đang làm trò cân bằng.
Xem bản gốcTrả lời0
TokenVelocity
· 07-21 22:10
Polkadot có thật sự ổn không? Hay chỉ là được chơi cho Suckers
Xem bản gốcTrả lời0
BearMarketSage
· 07-21 21:53
Không thể có cả cá và chân gấu.
Xem bản gốcTrả lời0
MidnightSeller
· 07-21 21:52
Hy sinh an toàn để đổi lấy tốc độ, gần như là chờ lên tầng thượng.
Xem bản gốcTrả lời0
PermabullPete
· 07-21 21:48
Hiểu rồi, nhưng điểm thì sao?
Xem bản gốcTrả lời0
MEVSandwichMaker
· 07-21 21:48
Hy sinh luôn có cái giá phải trả, chỉ là xem ai sẽ nổ trước.
Polkadot làm thế nào để thực hiện mở rộng không tin cậy, dẫn dắt tương lai Web3
Sự cân nhắc về khả năng mở rộng: Thách thức của Polkadot và Web3
Trong bối cảnh công nghệ blockchain đang hướng tới hiệu quả cao hơn, một vấn đề then chốt dần hiện rõ: Làm thế nào để mở rộng hiệu suất mà không hy sinh tính an toàn và tính linh hoạt của hệ thống? Đây không chỉ là thách thức ở cấp độ kỹ thuật, mà còn là sự lựa chọn sâu sắc trong thiết kế kiến trúc. Đối với hệ sinh thái Web3, một hệ thống nhanh hơn nếu được xây dựng trên nền tảng hy sinh lòng tin và tính an toàn thường khó có thể hỗ trợ đổi mới bền vững thực sự.
Là một trong những động lực quan trọng cho khả năng mở rộng Web3, Polkadot có phải đã hy sinh một số điều dưới mục tiêu cao về thông lượng và độ trễ thấp không? Mô hình rollup của nó có phải đã nhượng bộ về phân quyền, an ninh hoặc khả năng tương tác mạng không?
Bài viết này sẽ xoay quanh những vấn đề này, phân tích sâu sắc những sự lựa chọn và thỏa hiệp trong thiết kế khả năng mở rộng của Polkadot, đồng thời so sánh với các giải pháp của những chuỗi công khai chính khác, khám phá những lựa chọn khác nhau của chúng trong ba yếu tố: hiệu suất, an ninh và phi tập trung.
Những thách thức trong thiết kế mở rộng Polkadot
Sự cân bằng giữa tính linh hoạt và phi tập trung
Kiến trúc của Polkadot phụ thuộc vào mạng xác thực và chuỗi trung gian, điều này có thể mang lại rủi ro tập trung trong một số khía cạnh không? Có khả năng hình thành điểm lỗi đơn lẻ hoặc kiểm soát, từ đó ảnh hưởng đến đặc điểm phi tập trung của nó không?
Việc chạy Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian, giao tiếp của nó sử dụng cơ chế giao thức collator. Giao thức này hoàn toàn không cần cấp phép, không cần tin tưởng, bất kỳ ai có kết nối mạng đều có thể sử dụng nó, kết nối với một lượng nhỏ các nút chuỗi trung gian và gửi yêu cầu chuyển đổi trạng thái của rollup. Những yêu cầu này sẽ được xác minh bởi một core nào đó của chuỗi trung gian, chỉ cần thỏa mãn một điều kiện: phải là chuyển đổi trạng thái hợp lệ, nếu không trạng thái của rollup sẽ không được tiến lên.
Sự đánh đổi của mở rộng theo chiều dọc
Rollup có thể đạt được khả năng mở rộng theo chiều dọc bằng cách tận dụng kiến trúc đa lõi của Polkadot. Khả năng mới này được giới thiệu thông qua tính năng "mở rộng linh hoạt". Trong quá trình thiết kế, đã phát hiện ra rằng, vì việc xác minh khối rollup không cố định thực hiện trên một lõi nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Vì giao thức gửi khối đến chuỗi trung gian là không cần giấy phép và không cần tin tưởng, bất kỳ ai cũng có thể gửi khối để xác minh trên bất kỳ core nào được phân bổ cho rollup. Kẻ tấn công có thể lợi dụng điểm này, gửi lại các khối hợp pháp đã được xác minh trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó giảm tổng thể thông lượng và hiệu suất của rollup.
Mục tiêu của Polkadot là duy trì tính linh hoạt của rollup và hiệu quả sử dụng tài nguyên chuỗi trung gian mà không làm ảnh hưởng đến các đặc tính quan trọng của hệ thống.
Sequencer có đáng tin cậy không?
Một giải pháp đơn giản là thiết lập giao thức là "có giấy phép": ví dụ, áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng rằng bộ sắp xếp sẽ không có hành vi độc hại, từ đó đảm bảo tính khả thi của rollup.
Tuy nhiên, trong triết lý thiết kế của Polkadot, chúng ta không thể có bất kỳ giả định nào về độ tin cậy của sequencer, vì để duy trì các đặc tính "không cần tin cậy" và "không cần cấp phép" của hệ thống. Bất kỳ ai cũng nên có thể sử dụng giao thức collator để gửi yêu cầu chuyển trạng thái rollup.
Polkadot: Giải pháp không thỏa hiệp
Giải pháp cuối cùng mà Polkadot chọn là: giao hoàn toàn vấn đề cho hàm chuyển trạng thái của rollup (Runtime) để giải quyết. Runtime là nguồn đáng tin cậy duy nhất cho tất cả thông tin đồng thuận, vì vậy phải tuyên bố rõ ràng trong đầu ra rằng nên thực hiện xác minh trên core Polkadot nào.
Thiết kế này đảm bảo cả tính linh hoạt và an ninh. Polkadot sẽ thực hiện lại các chuyển trạng thái của rollup trong quy trình khả dụng và đảm bảo tính chính xác của phân bổ core thông qua giao thức kinh tế mã hóa ELVES.
Trước khi ghi dữ liệu vào lớp khả dụng của Polkadot trong bất kỳ khối rollup nào, một nhóm khoảng 5 người xác thực sẽ xác minh tính hợp pháp của nó. Họ nhận các biên lai ứng cử và chứng minh tính hợp lệ được gửi bởi bộ sắp xếp, trong đó bao gồm khối rollup và chứng minh lưu trữ tương ứng. Những thông tin này sẽ được chuyển cho hàm xác thực của chuỗi song song xử lý, và sẽ được thực hiện lại bởi các xác thực trên chuỗi tiếp hợp.
Kết quả xác minh bao gồm một bộ chọn lõi, được sử dụng để chỉ định xác minh khối trên lõi nào. Người xác minh sẽ so sánh chỉ số đó với lõi mà mình chịu trách nhiệm; nếu không khớp, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo rằng hệ thống luôn giữ được các thuộc tính không cần tin cậy và không cần cấp phép, tránh hành vi thao túng vị trí xác minh của những kẻ xấu như trình sắp xếp, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core, nó vẫn giữ được tính linh hoạt.
An toàn
Trong quá trình theo đuổi khả năng mở rộng, Polkadot không hề thỏa hiệp về mặt an toàn. An ninh của rollup được đảm bảo bởi chuỗi trung gian, chỉ cần một bộ sắp xếp trung thực là có thể duy trì sự sống.
Thông qua giao thức ELVES, Polkadot mở rộng tính bảo mật của mình hoàn toàn đến tất cả các rollup, xác minh tất cả các phép toán trên core mà không cần phải hạn chế hoặc giả định về số lượng core được sử dụng.
Do đó, rollup của Polkadot có thể đạt được sự mở rộng thực sự mà không hy sinh tính bảo mật.
Độ phổ quát
Mở rộng linh hoạt sẽ không giới hạn tính lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện các tính toán Turing đầy đủ trong môi trường WebAssembly, miễn là mỗi lần thực hiện hoàn thành trong vòng 2 giây. Nhờ vào mở rộng linh hoạt, tổng khối lượng tính toán có thể thực hiện trong mỗi chu kỳ 6 giây được cải thiện, nhưng loại hình tính toán không bị ảnh hưởng.
Độ phức tạp
Thông lượng cao hơn và độ trễ thấp hơn sẽ không thể tránh khỏi việc đưa ra sự phức tạp, đây là cách duy nhất để chấp nhận trong thiết kế hệ thống.
Rollup có thể điều chỉnh tài nguyên một cách động thông qua giao diện Agile Coretime để duy trì mức độ an toàn đồng nhất. Chúng cũng cần thực hiện một phần yêu cầu RFC103 để phù hợp với các tình huống sử dụng khác nhau.
Sự phức tạp cụ thể phụ thuộc vào chiến lược quản lý tài nguyên của rollup, các chiến lược này có thể dựa vào các biến trên chuỗi hoặc ngoài chuỗi. Ví dụ:
Chiến lược đơn giản: Luôn sử dụng một số lượng core cố định, hoặc điều chỉnh thủ công bên ngoài.
Chiến lược nhẹ: Giám sát tải giao dịch cụ thể trong mempool của nút;
Chiến lược tự động hóa: Gọi dịch vụ coretime trước bằng cách sử dụng dữ liệu lịch sử và giao diện XCM để cấu hình tài nguyên.
Mặc dù cách thức tự động hóa hiệu quả hơn, nhưng chi phí thực hiện và kiểm tra cũng tăng đáng kể.
khả năng tương tác
Polkadot hỗ trợ khả năng tương tác giữa các rollup khác nhau, trong khi khả năng mở rộng linh hoạt không ảnh hưởng đến lưu lượng tin nhắn.
Giao tiếp tin nhắn giữa các rollup được thực hiện bởi lớp truyền tải dưới, không gian khối giao tiếp của mỗi rollup là cố định, không liên quan đến số lượng lõi được phân bổ.
Trong tương lai, Polkadot cũng sẽ hỗ trợ truyền tin ngoài chuỗi, với chuỗi trung gian đóng vai trò là mặt kiểm soát, thay vì mặt dữ liệu. Cập nhật này sẽ nâng cao khả năng giao tiếp giữa các rollup cùng với khả năng mở rộng linh hoạt, từ đó tăng cường khả năng mở rộng theo chiều dọc của hệ thống.
Các giao thức khác đã đưa ra những thỏa hiệp nào?
Như mọi người đều biết, việc nâng cao hiệu suất thường phải hy sinh sự phi tập trung và an toàn. Nhưng từ góc độ hệ số Nakamoto, ngay cả khi một số đối thủ của Polkadot có mức độ phi tập trung thấp, hiệu suất của chúng cũng không được như mong đợi.
Solana
Solana không sử dụng kiến trúc phân đoạn của Polkadot hay Ethereum, mà thay vào đó thực hiện khả năng mở rộng bằng kiến trúc đơn lớp với hiệu suất cao, dựa vào chứng minh lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, với TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lập lịch lãnh đạo được công khai trước và có thể xác minh.
Vào đầu mỗi epoch (khoảng hai ngày hoặc 432.000 slot), các slot được phân bổ theo lượng staked;
Càng nhiều stake, càng nhiều phân bổ. Ví dụ, một người xác thực stake 1% sẽ có khoảng 1% cơ hội tạo khối;
Tất cả các thợ mỏ đều được công bố trước, làm tăng rủi ro mạng bị tấn công DDoS có định hướng và thường xuyên bị ngưng hoạt động.
PoH và xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung hóa của các nút xác thực. Nút càng nhiều staked thì cơ hội ra khối càng lớn, các nút nhỏ gần như không có slot, làm gia tăng thêm sự tập trung hóa, đồng thời cũng tăng nguy cơ hệ thống bị tê liệt sau khi bị tấn công.
Solana đã hy sinh khả năng phi tập trung và khả năng chống tấn công để theo đuổi TPS, hệ số Nakamoto của nó chỉ là 20, thấp hơn nhiều so với 172 của Polkadot.
TON
TON tuyên bố TPS có thể đạt 104.715, nhưng con số này được đạt được trên mạng thử nghiệm riêng, với 256 nút, trong điều kiện mạng và phần cứng lý tưởng. Trong khi đó, Polkadot đã đạt tới 128K TPS trên mạng công cộng phi tập trung.
Cơ chế đồng thuận của TON có những rủi ro về an ninh: danh tính của các nút xác thực phân đoạn sẽ bị lộ ra sớm. Bản trắng của TON cũng chỉ rõ rằng, mặc dù điều này có thể tối ưu hóa băng thông, nhưng cũng có thể bị khai thác xấu. Do thiếu cơ chế "phá sản của người đánh cược", kẻ tấn công có thể chờ đợi một phân đoạn hoàn toàn nằm trong sự kiểm soát của mình, hoặc thông qua cuộc tấn công DDoS để chặn những người xác thực trung thực, từ đó thay đổi trạng thái.
So với đó, các validator của Polkadot được phân bổ ngẫu nhiên và tiết lộ muộn, kẻ tấn công không thể biết trước danh tính của validator, cuộc tấn công phải đặt cược toàn bộ để thành công, chỉ cần có một validator trung thực khởi xướng tranh chấp, cuộc tấn công sẽ thất bại và dẫn đến tổn thất cho kẻ tấn công.
Avalanche
Avalanche sử dụng kiến trúc mạng chính + mạng con để mở rộng, mạng chính bao gồm X-Chain (chuyển tiền, ~4.500 TPS), C-Chain (hợp đồng thông minh, ~100-200 TPS), P-Chain (quản lý các xác nhận viên và mạng con).
Mỗi subnet lý thuyết có thể đạt TPS khoảng ~5,000, tương tự như tư tưởng của Polkadot: giảm tải cho từng shard để đạt được khả năng mở rộng. Nhưng Avalanche cho phép các validator tự do chọn tham gia vào subnet, và subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi sự phi tập trung và an toàn.
Tại Polkadot, tất cả các rollup đều chia sẻ bảo đảm an ninh thống nhất; trong khi đó, các subnet của Avalanche không có bảo đảm an ninh mặc định, một số thậm chí có thể hoàn toàn tập trung. Nếu muốn nâng cao an ninh, vẫn cần phải thỏa hiệp về hiệu suất và khó khăn trong việc cung cấp cam kết an ninh xác định.
Ethereum
Chiến lược mở rộng của Ethereum là đặt cược vào khả năng mở rộng của lớp rollup, thay vì giải quyết vấn đề trực tiếp ở lớp cơ sở. Cách tiếp cận này về bản chất không giải quyết vấn đề mà chỉ chuyển vấn đề lên lớp trên của ngăn xếp.
Optimistic Rollup
Hiện nay, hầu hết các Optimistic rollup đều là phi tập trung (thậm chí có những cái chỉ có một sequencer), tồn tại các vấn đề như thiếu an toàn, cách biệt lẫn nhau, độ trễ cao (cần phải chờ thời gian chứng minh gian lận, thường là vài ngày).
ZK Rollup
Việc triển khai ZK rollup bị giới hạn bởi khối lượng dữ liệu có thể xử lý cho một giao dịch. Nhu cầu tính toán để tạo ra bằng chứng không biết rất cao, và cơ chế "người chiến thắng nhận hết" dễ dẫn đến sự tập trung của hệ thống. Để đảm bảo TPS, ZK rollup thường giới hạn khối lượng giao dịch cho mỗi lô, và trong những thời điểm có nhu cầu cao sẽ gây ra tắc nghẽn mạng, giá gas tăng, ảnh hưởng đến trải nghiệm của người dùng.
So với đó, chi phí của ZK rollup hoàn toàn Turing là khoảng 2x10^6 lần so với giao thức an ninh kinh tế cốt lõi của Polkadot.
Ngoài ra, vấn đề khả năng sẵn có của dữ liệu ZK rollup cũng sẽ làm trầm trọng thêm những hạn chế của nó. Để đảm bảo bất kỳ ai cũng có thể xác minh giao dịch, vẫn cần cung cấp dữ liệu giao dịch đầy đủ. Điều này thường phụ thuộc vào các giải pháp khả năng sẵn có dữ liệu bổ sung, làm tăng thêm chi phí và phí tổn cho người dùng.
Kết luận
Cuối cùng của khả năng mở rộng, không nên là sự thỏa hiệp.
So với các chuỗi công khai khác, Polkadot không chọn con đường đánh đổi giữa tập trung hóa và hiệu suất, hay đánh đổi giữa niềm tin đã được thiết lập và hiệu quả, mà thay vào đó đạt được sự cân bằng đa chiều giữa tính bảo mật, phi tập trung và hiệu suất cao thông qua mở rộng linh hoạt, thiết kế giao thức không cần cấp phép, lớp bảo mật thống nhất và cơ chế quản lý tài nguyên linh hoạt.
Trong bối cảnh theo đuổi việc ứng dụng quy mô lớn hơn, "mở rộng không tin cậy" mà Polkadot kiên trì có lẽ mới thật sự là giải pháp hỗ trợ cho sự phát triển lâu dài của Web3.