Sự cân nhắc về khả năng mở rộng của Blockchain: Lựa chọn giữa Polkadot và Web3
Trong bối cảnh blockchain không ngừng theo đuổi việc nâng cao hiệu suất ngày nay, một vấn đề then chốt dần nổi lên: Làm thế nào để cải thiện khả năng mở rộng 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 độ công nghệ, 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, chỉ đơn giản theo đuổi hệ thống nhanh hơn mà bỏ qua niềm tin và tính an toàn, sẽ khó có thể hỗ trợ đổi mới thực sự bền vững.
Là một động lực quan trọng cho khả năng mở rộng Web3, Polkadot có phải đã thực hiện một số sự đánh đổi trong quá trình theo đuổi thông lượng cao và độ trễ thấp? Mô hình rollup của nó có phải đã thỏa hiệp về phi tập trung, an ninh hoặc khả năng tương tác mạng không?
Bài viết này sẽ thảo luận xung quanh những vấn đề này, phân tích sâu về sự cân nhắc trong thiết kế khả năng mở rộng của Polkadot và so sánh với các giải pháp của các 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 giữa hiệu suất, an toàn và phi tập trung.
Những thách thức trong thiết kế mở rộng của 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 tiếp nối, điều này có thể gây ra 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 hoặc kiểm soát, từ đó ảnh hưởng đến đặc tính phi tập trung của nó không?
Việc vận hành 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 cậy, bất kỳ ai có kết nối mạng đều có thể sử dụng nó, kết nối một số 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 qua một core nào đó của chuỗi trung gian, chỉ cần đáp ứng 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 thúc đẩy.
Sự cân nhắc về 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 core của Polkadot. Khả năng mới này được giới thiệu bởi chức năng "mở rộng linh hoạt". Trong quá trình thiết kế, đã phát hiện rằng do việc xác minh khối rollup không cố định ở một core nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Do vì giao thức gửi khối đến chuỗi trung gian là không cần cấp phép và không cần niềm tin, bất kỳ ai cũng có thể gửi khối đến bất kỳ core nào được phân bổ cho rollup để xác minh. Kẻ tấn công có thể tận dụng điều này để gửi lại nhiều lần 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 nguồn lực một cách ác ý, từ đó giảm tổng lượng thông qua 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à tối ưu hóa việc sử dụng tài nguyên của chuỗi trung gian mà không ả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 thành "có giấy phép": ví dụ như áp dụng cơ chế danh sách trắng, hoặc mặc định tin cậy vào bộ sắp xếp sẽ không có hành vi độc hại, từ đó đảm bảo tính hoạt động của rollup.
Tuy nhiên, trong triết lý thiết kế của Polkadot, chúng ta không thể đưa ra bất kỳ giả định nào về sequencer, vì cần duy trì các đặc tính "không cần tin cậy" và "không cần sự cho 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 đổi 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 lựa 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 thông tin đồng thuận duy nhất đáng tin cậy, vì vậy phải tuyên bố rõ ràng trong đầu ra rằng cần thực hiện xác minh trên Polkadot core nào.
Thiết kế này đảm bảo bảo mật kép giữa tính linh hoạt và an toàn. Polkadot sẽ thực hiện lại quá trình chuyển đổi 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 bất kỳ khối rollup nào được ghi vào lớp khả dụng dữ liệu của Polkadot, một nhóm gồm khoảng 5 nhà xác thực sẽ xác minh tính hợp pháp của nó trước. Họ nhận các biên lai ứng cử viên và chứng minh tính hợp lệ do bộ sắp xếp gửi đến, trong đó chứa 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 chuỗi song song xử lý, và được các nhà xác thực trên chuỗi trung gian thực hiện lại.
Kết quả xác minh bao gồm một core selector, được sử dụng để chỉ định nên xác minh khối ở core nào. Người xác minh sẽ so sánh chỉ số này với core mà họ phụ trách; nếu không一致, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo rằng hệ thống luôn duy trì thuộc tính không cần tin cậy và không cần sự cho phép, tránh việc các tác nhân độc hại như bộ sắp xếp thao túng vị trí xác thực, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core cũng có thể duy trì sự 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 ninh. 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à đủ để duy trì sự sống.
Với giao thức ELVES, Polkadot mở rộng toàn bộ tính bảo mật của nó đến tất cả các rollup, xác thực tất cả các phép toán trên core mà không cần bất kỳ giới hạn hay giả định nào về số lượng core được sử dụng.
Do đó, rollup của Polkadot có thể đạt được khả năng mở rộng thực sự mà không hy sinh tính bảo mật.
Tính phổ quát
Mở rộng linh hoạt sẽ không giới hạn khả năng lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện tính toán hoàn chỉnh Turing trong môi trường WebAssembly, miễn là thực hiện một lầ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 nâng cao, 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 không thể tránh khỏi sẽ dẫn đến sự phức tạp, đây là cách duy nhất có thể 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, nhằm duy trì mức độ an toàn đồng nhất. Chúng cũng cần đạt được một phần yêu cầu RFC103 để phù hợp với các kịch bản sử dụng khác nhau.
Cụ thể, độ phức tạp phụ thuộc vào chiến lược quản lý tài nguyên của rollup, những 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 qua chuỗi 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 trước dịch vụ coretime để cấu hình tài nguyên thông qua dữ liệu lịch sử và giao diện XCM.
Mặc dù phương pháp tự động hóa hiệu quả hơn, nhưng chi phí thực hiện và thử nghiệm cũng tăng đáng kể.
Tính 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 thông lượng truyền tải tin nhắn.
Việc truyền thông tin giữa các rollup được thực hiện bởi tầng truyền dẫn dưới, không gian khối thông tin của mỗi rollup là cố định, không liên quan đến số lượng lõi được phân bổ cho nó.
Trong tương lai, Polkadot sẽ hỗ trợ việc truyền tin ngoài chuỗi, với chuỗi trung gian làm mặt điều khiển, thay vì mặt dữ liệu. Cải tiến này sẽ nâng cao khả năng giao tiếp giữa các rollup cùng với việc 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.
Sự cân nhắc của các giao thức khác
Như mọi người đã biết, việc nâng cao hiệu suất thường phải trả giá bằng việc hy sinh tính phi tập trung và an toàn. Tuy nhiên, 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 như mong đợi.
Solana
Solana không sử dụng kiến trúc phân đoạn của Polkadot hoặc Ethereum, mà thay vào đó là kiến trúc một lớp với khả năng thông lượng cao để đạt được tính mở rộng, phụ thuộc vào chứng minh lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên người lãnh đạo, TPS lý thuyết có thể đạt tới 65,000.
Một thiết kế quan trọng là cơ chế lập lịch lãnh đạo được công khai và có thể xác minh trước.
Vào đầu mỗi epoch (khoảng hai ngày hoặc 432,000 slot), phân bổ slot theo số lượng stake;
Càng nhiều staking, càng nhiều phân bổ. Ví dụ, staking 1% của người xác minh sẽ nhận được khoảng 1% cơ hội tạo khối;
Tất cả những người tạo khối được công bố trước, làm tăng nguy cơ mạng bị tấn công DDoS có định hướng và thường xuyên bị ngắt quã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ó nhiều cổ phần hơn có cơ hội tạo khối lớn hơn, trong khi các nút nhỏ gần như không có slot, càng làm tăng sự tập trung hóa và cũng làm tăng rủi ro 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 Polkadot với 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này được thực hiện trong mạng thử nghiệm riêng, 256 nút, điều kiện mạng và phần cứng lý tưởng. Trong khi đó, Polkadot đã đạt 128K TPS trên mạng công khai phi tập trung.
Cơ chế đồng thuận của TON có lỗ hổng bảo mật: danh tính của các nút xác thực phân đoạn sẽ bị lộ trước. Sách trắng của TON cũng chỉ ra 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 một cách ác ý. Do thiếu cơ chế "phá sản của người chơi", kẻ tấn công có thể chờ đợi một phân đoạn bị kiểm soát hoàn toàn hoặc sử dụng cuộc tấn công DDoS để ngăn chặn các nút xác thực trung thực, từ đó thay đổi trạng thái.
So với đó, các người xác thực 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 người xác thực, cuộc tấn công cần phải cược toàn bộ để thành công, chỉ cần có một người xác thực 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 việc kẻ tấn công mất đi số vốn đã đặt cược.
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 khoản, ~4,500 TPS), C-Chain (hợp đồng thông minh, ~100-200 TPS), P-Chain (quản lý các xác thực viên và mạng con).
Mỗi subnet lý thuyết TPS có thể đạt ~5,000, tương tự như ý tưởng của Polkadot: giảm tải cho từng shard để đạt được khả năng mở rộng. Tuy nhiên, Avalanche cho phép các validator tự do chọn tham gia subnet, và subnet có thể thiết lập các yêu cầu bổ sung về địa lý, KYC, v.v., hy sinh tính phi tập trung và độ an toàn.
Tại Polkadot, tất cả các rollup chia sẻ đảm bảo an toàn thống nhất; trong khi các subnet của Avalanche không có đảm bảo an toàn mặc định, một số thậm chí có thể hoàn toàn tập trung. Nếu muốn tăng cường an toàn, vẫn cần phải thỏa hiệp về hiệu suất, và khó có thể cung cấp cam kết an toàn 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 phía trên của ngăn xếp.
Optimistic Rollup
Hiện tại hầu hết các Optimistic rollup đều là tập trung (một số thậm chí chỉ có một sequencer), tồn tại các vấn đề như thiếu an toàn, bị cô lập với 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 thực hiện ZK rollup bị giới hạn bởi khối lượng dữ liệu có thể xử lý cho mỗi 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 tất cả" dễ dẫn đến sự tập trung hệ thống. Để đảm bảo TPS, ZK rollup thường giới hạn khối lượng giao dịch trong mỗi lô, khi nhu cầu cao sẽ gây ra tắc nghẽn mạng, tăng gas và ảnh hưởng đến trải nghiệm người dùng.
So với đó, chi phí của ZK rollup hoàn chỉnh Turing khoảng gấp 2x10^6 lần so với giao thức bảo mật kinh tế chính của Polkadot.
Ngoài ra, vấn đề khả năng sử dụng dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm những bất lợi 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ử dụng dữ liệu bổ sung, làm tăng thêm chi phí và phí 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 đi theo con đường đánh đổi giữa tập trung hóa để đổi lấy hiệu suất, hay đánh đổi giữa niềm tin đã được thiết lập để đổi lấy hiệu quả, mà thay vào đó, thông qua việc mở rộng linh hoạt, thiết kế giao thức không cần cấp phép, lớp an toàn thống nhất và cơ chế quản lý tài nguyên linh hoạt, đã đạt được sự cân bằng đa chiều giữa an toàn, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi mà việc theo đuổi ứng dụng quy mô lớn đang diễn ra, "mở rộng không tin cậy" mà Polkadot kiên định có lẽ mới chính là giải pháp thực sự có thể hỗ trợ 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.
16 thích
Phần thưởng
16
6
Đăng lại
Chia sẻ
Bình luận
0/400
Fren_Not_Food
· 07-23 13:22
Dự án được quảng bá khá tốt, hãy xem xét hiệu suất thực tế.
Xem bản gốcTrả lời0
BlockchainDecoder
· 07-23 11:10
Theo dữ liệu gần đây từ nhóm nghiên cứu Cho, tps của chuỗi đơn thường thấp hơn 3k, vấn đề cân nhắc cần phải được vượt qua.
Polkadot không thỏa hiệp về khả năng mở rộng: Lựa chọn mới cho hệ sinh thái Web3
Sự cân nhắc về khả năng mở rộng của Blockchain: Lựa chọn giữa Polkadot và Web3
Trong bối cảnh blockchain không ngừng theo đuổi việc nâng cao hiệu suất ngày nay, một vấn đề then chốt dần nổi lên: Làm thế nào để cải thiện khả năng mở rộng 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 độ công nghệ, 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, chỉ đơn giản theo đuổi hệ thống nhanh hơn mà bỏ qua niềm tin và tính an toàn, sẽ khó có thể hỗ trợ đổi mới thực sự bền vững.
Là một động lực quan trọng cho khả năng mở rộng Web3, Polkadot có phải đã thực hiện một số sự đánh đổi trong quá trình theo đuổi thông lượng cao và độ trễ thấp? Mô hình rollup của nó có phải đã thỏa hiệp về phi tập trung, an ninh hoặc khả năng tương tác mạng không?
Bài viết này sẽ thảo luận xung quanh những vấn đề này, phân tích sâu về sự cân nhắc trong thiết kế khả năng mở rộng của Polkadot và so sánh với các giải pháp của các 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 giữa hiệu suất, an toàn và phi tập trung.
Những thách thức trong thiết kế mở rộng của 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 tiếp nối, điều này có thể gây ra 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 hoặc kiểm soát, từ đó ảnh hưởng đến đặc tính phi tập trung của nó không?
Việc vận hành 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 cậy, bất kỳ ai có kết nối mạng đều có thể sử dụng nó, kết nối một số 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 qua một core nào đó của chuỗi trung gian, chỉ cần đáp ứng 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 thúc đẩy.
Sự cân nhắc về 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 core của Polkadot. Khả năng mới này được giới thiệu bởi chức năng "mở rộng linh hoạt". Trong quá trình thiết kế, đã phát hiện rằng do việc xác minh khối rollup không cố định ở một core nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Do vì giao thức gửi khối đến chuỗi trung gian là không cần cấp phép và không cần niềm tin, bất kỳ ai cũng có thể gửi khối đến bất kỳ core nào được phân bổ cho rollup để xác minh. Kẻ tấn công có thể tận dụng điều này để gửi lại nhiều lần 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 nguồn lực một cách ác ý, từ đó giảm tổng lượng thông qua 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à tối ưu hóa việc sử dụng tài nguyên của chuỗi trung gian mà không ả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 thành "có giấy phép": ví dụ như áp dụng cơ chế danh sách trắng, hoặc mặc định tin cậy vào bộ sắp xếp sẽ không có hành vi độc hại, từ đó đảm bảo tính hoạt động của rollup.
Tuy nhiên, trong triết lý thiết kế của Polkadot, chúng ta không thể đưa ra bất kỳ giả định nào về sequencer, vì cần duy trì các đặc tính "không cần tin cậy" và "không cần sự cho 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 đổi 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 lựa 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 thông tin đồng thuận duy nhất đáng tin cậy, vì vậy phải tuyên bố rõ ràng trong đầu ra rằng cần thực hiện xác minh trên Polkadot core nào.
Thiết kế này đảm bảo bảo mật kép giữa tính linh hoạt và an toàn. Polkadot sẽ thực hiện lại quá trình chuyển đổi 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 bất kỳ khối rollup nào được ghi vào lớp khả dụng dữ liệu của Polkadot, một nhóm gồm khoảng 5 nhà xác thực sẽ xác minh tính hợp pháp của nó trước. Họ nhận các biên lai ứng cử viên và chứng minh tính hợp lệ do bộ sắp xếp gửi đến, trong đó chứa 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 chuỗi song song xử lý, và được các nhà xác thực trên chuỗi trung gian thực hiện lại.
Kết quả xác minh bao gồm một core selector, được sử dụng để chỉ định nên xác minh khối ở core nào. Người xác minh sẽ so sánh chỉ số này với core mà họ phụ trách; nếu không一致, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo rằng hệ thống luôn duy trì thuộc tính không cần tin cậy và không cần sự cho phép, tránh việc các tác nhân độc hại như bộ sắp xếp thao túng vị trí xác thực, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core cũng có thể duy trì sự 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 ninh. 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à đủ để duy trì sự sống.
Với giao thức ELVES, Polkadot mở rộng toàn bộ tính bảo mật của nó đến tất cả các rollup, xác thực tất cả các phép toán trên core mà không cần bất kỳ giới hạn hay giả định nào về số lượng core được sử dụng.
Do đó, rollup của Polkadot có thể đạt được khả năng mở rộng thực sự mà không hy sinh tính bảo mật.
Tính phổ quát
Mở rộng linh hoạt sẽ không giới hạn khả năng lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện tính toán hoàn chỉnh Turing trong môi trường WebAssembly, miễn là thực hiện một lầ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 nâng cao, 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 không thể tránh khỏi sẽ dẫn đến sự phức tạp, đây là cách duy nhất có thể 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, nhằm duy trì mức độ an toàn đồng nhất. Chúng cũng cần đạt được một phần yêu cầu RFC103 để phù hợp với các kịch bản sử dụng khác nhau.
Cụ thể, độ phức tạp phụ thuộc vào chiến lược quản lý tài nguyên của rollup, những 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ụ:
Mặc dù phương pháp tự động hóa hiệu quả hơn, nhưng chi phí thực hiện và thử nghiệm cũng tăng đáng kể.
Tính 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 thông lượng truyền tải tin nhắn.
Việc truyền thông tin giữa các rollup được thực hiện bởi tầng truyền dẫn dưới, không gian khối thông tin của mỗi rollup là cố định, không liên quan đến số lượng lõi được phân bổ cho nó.
Trong tương lai, Polkadot sẽ hỗ trợ việc truyền tin ngoài chuỗi, với chuỗi trung gian làm mặt điều khiển, thay vì mặt dữ liệu. Cải tiến này sẽ nâng cao khả năng giao tiếp giữa các rollup cùng với việc 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.
Sự cân nhắc của các giao thức khác
Như mọi người đã biết, việc nâng cao hiệu suất thường phải trả giá bằng việc hy sinh tính phi tập trung và an toàn. Tuy nhiên, 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 như mong đợi.
Solana
Solana không sử dụng kiến trúc phân đoạn của Polkadot hoặc Ethereum, mà thay vào đó là kiến trúc một lớp với khả năng thông lượng cao để đạt được tính mở rộng, phụ thuộc vào chứng minh lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên người lãnh đạo, TPS lý thuyết có thể đạt tới 65,000.
Một thiết kế quan trọng là cơ chế lập lịch lãnh đạo được công khai và có thể xác minh trước.
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ó nhiều cổ phần hơn có cơ hội tạo khối lớn hơn, trong khi các nút nhỏ gần như không có slot, càng làm tăng sự tập trung hóa và cũng làm tăng rủi ro 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 Polkadot với 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này được thực hiện trong mạng thử nghiệm riêng, 256 nút, điều kiện mạng và phần cứng lý tưởng. Trong khi đó, Polkadot đã đạt 128K TPS trên mạng công khai phi tập trung.
Cơ chế đồng thuận của TON có lỗ hổng bảo mật: danh tính của các nút xác thực phân đoạn sẽ bị lộ trước. Sách trắng của TON cũng chỉ ra 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 một cách ác ý. Do thiếu cơ chế "phá sản của người chơi", kẻ tấn công có thể chờ đợi một phân đoạn bị kiểm soát hoàn toàn hoặc sử dụng cuộc tấn công DDoS để ngăn chặn các nút xác thực trung thực, từ đó thay đổi trạng thái.
So với đó, các người xác thực 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 người xác thực, cuộc tấn công cần phải cược toàn bộ để thành công, chỉ cần có một người xác thực 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 việc kẻ tấn công mất đi số vốn đã đặt cược.
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 khoản, ~4,500 TPS), C-Chain (hợp đồng thông minh, ~100-200 TPS), P-Chain (quản lý các xác thực viên và mạng con).
Mỗi subnet lý thuyết TPS có thể đạt ~5,000, tương tự như ý tưởng của Polkadot: giảm tải cho từng shard để đạt được khả năng mở rộng. Tuy nhiên, Avalanche cho phép các validator tự do chọn tham gia subnet, và subnet có thể thiết lập các yêu cầu bổ sung về địa lý, KYC, v.v., hy sinh tính phi tập trung và độ an toàn.
Tại Polkadot, tất cả các rollup chia sẻ đảm bảo an toàn thống nhất; trong khi các subnet của Avalanche không có đảm bảo an toàn mặc định, một số thậm chí có thể hoàn toàn tập trung. Nếu muốn tăng cường an toàn, vẫn cần phải thỏa hiệp về hiệu suất, và khó có thể cung cấp cam kết an toàn 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 phía trên của ngăn xếp.
Optimistic Rollup
Hiện tại hầu hết các Optimistic rollup đều là tập trung (một số thậm chí chỉ có một sequencer), tồn tại các vấn đề như thiếu an toàn, bị cô lập với 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 thực hiện ZK rollup bị giới hạn bởi khối lượng dữ liệu có thể xử lý cho mỗi 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 tất cả" dễ dẫn đến sự tập trung hệ thống. Để đảm bảo TPS, ZK rollup thường giới hạn khối lượng giao dịch trong mỗi lô, khi nhu cầu cao sẽ gây ra tắc nghẽn mạng, tăng gas và ảnh hưởng đến trải nghiệm người dùng.
So với đó, chi phí của ZK rollup hoàn chỉnh Turing khoảng gấp 2x10^6 lần so với giao thức bảo mật kinh tế chính của Polkadot.
Ngoài ra, vấn đề khả năng sử dụng dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm những bất lợi 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ử dụng dữ liệu bổ sung, làm tăng thêm chi phí và phí 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 đi theo con đường đánh đổi giữa tập trung hóa để đổi lấy hiệu suất, hay đánh đổi giữa niềm tin đã được thiết lập để đổi lấy hiệu quả, mà thay vào đó, thông qua việc mở rộng linh hoạt, thiết kế giao thức không cần cấp phép, lớp an toàn thống nhất và cơ chế quản lý tài nguyên linh hoạt, đã đạt được sự cân bằng đa chiều giữa an toàn, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi mà việc theo đuổi ứng dụng quy mô lớn đang diễn ra, "mở rộng không tin cậy" mà Polkadot kiên định có lẽ mới chính là giải pháp thực sự có thể hỗ trợ sự phát triển lâu dài của Web3.