Sự cân bằng giữa khả năng mở rộng và an ninh: Thiết kế kiến trúc Web3 của Polkadot
Trong bối cảnh công nghệ blockchain không ngừng theo đuổi hiệu suất cao hơn, một vấn đề then chốt dần dần nổi lên: làm thế nào để nâng cao 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 độ công nghệ, mà còn liên quan đến những cân nhắc 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 tốc độ cao nếu đánh đổi bằng sự tin tưởng và an toàn thường khó có thể hỗ trợ những đổ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ố thỏa hiệp trong quá trình theo đuổi thông lượng cao 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 hay khả năng tương tác mạng không? Bài viết này sẽ thảo luận về những câu hỏi này, phân tích sâu sắc các sự lựa chọn và thỏa hiệp của Polkadot trong thiết kế khả năng mở rộng, 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á sự lựa chọn khác nhau của chúng trong ba yếu tố: hiệu suất, an ninh và phân quyền.
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ể gây ra rủi ro tập trung ở một số khía cạnh không? Có khả năng hình thành điểm thất bại duy nhất 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 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 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 thực bởi một core nào đó của chuỗi trung gian, chỉ cần đáp ứng một điều kiện tiên quyết: 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 triển.
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 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 do việc xác thực 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 phép và không cần tin cậy, 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ể lợi dụng điều 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 hại, từ đó giảm tổng công suất và hiệu quả của rollup.
Mục tiêu của Polkadot là duy trì tính linh hoạt của rollup và khai thác hiệu quả tài nguyên của chuỗi tiếp hợp mà không ảnh hưởng đến các đặc tính chính của hệ thống.
Vấn đề tin cậy của Sequencer
Một giải pháp đơn giản là đặt giao thức thành "có giấy phép": chẳng hạn như áp dụng cơ chế danh sách trắng, hoặc tin tưởng mặc định rằng các trình sắp xếp sẽ không có hành vi ác ý, 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ể đư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 giấy 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 chọn là: hoàn toàn giao 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 thực trên lõi Polkadot nào.
Thiết kế này đảm bảo được cả tính linh hoạt và an toàn. Polkadot sẽ thực hiện lại các chuyển đổi trạng thái của rollup trong quy trình khả dụng, và thông qua giao thức kinh tế mã hóa ELVES đảm bảo tính chính xác của phân bổ core.
Trước khi ghi dữ liệu vào lớp khả dụng dữ liệu của Polkadot trong bất kỳ khối rollup nào, một nhóm gồm khoảng 5 người xác thực sẽ kiểm tra tính hợp lệ của nó. Họ nhận các biên bản ứng cử viên và bằng chứng tính hợp lệ từ bộ sắp xếp, trong đó bao gồm khối rollup và bằng chứng lưu trữ tương ứng. Những thông tin này sẽ được chuyển cho chức năng xác thực của chuỗi song song xử lý, và sẽ được các người xác thực trên chuỗi trung gian thực hiện lại.
Kết quả xác thực bao gồm một bộ chọn core, được sử dụng để chỉ định core nào sẽ xác thực khối. Người xác thực sẽ so sánh chỉ mục đó với core mà họ phụ trách; 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 duy trì tính chất không cần tin cậy và không cần sự cho phép, tránh các hành vi độc hại như can thiệp vào vị trí xác thực của bộ sắp xếp, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core cũng có thể duy trì 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ề tính bảo mật. 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.
Nhờ vào giao thức ELVES, Polkadot đã mở rộng tính bảo mật của mình một cách toàn diệ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 đặt bất kỳ giới hạn hoặc 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 tổng quát
Mở rộng linh hoạt sẽ không hạn chế khả năng 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à việc thực hiện một lần hoàn thành trong vòng 2 giây. Nhờ vào việc 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 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 chắc chắn sẽ dẫn đến 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 nhất quán. 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, mà 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 số lượng core cố định, hoặc điều chỉnh thủ công ngoại tuyến.
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à kiểm tra cũng tăng lên đá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 sẽ không ảnh hưởng đến thông lượng truyền tải tin nhắn.
Giao tiếp tin nhắn qua 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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi trung gian đóng vai trò là 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 khả năng mở rộng linh hoạt, tăng cường khả năng mở rộng theo chiều dọc của hệ thống.
Sự đánh đổi của các giao thức khác
Như chúng ta đã biết, việc nâng cao hiệu suất thường phải hy sinh tính phi tập trung và an ninh. 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 hơn, hiệu suất của chúng cũng không đạt yêu cầu.
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 đó sử dụng kiến trúc đơn lớp với khả năng xử lý cao để đạt được khả năng mở rộng, dựa vào chứng minh lịch sử, xử lý song song CPU và cơ chế đồng thuận dựa trên người đứng đầu, lý thuyết TPS 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 lượng stake;
Càng nhiều staked, càng nhiều phân phối. Ví dụ, một validator stake 1% sẽ có khoảng 1% cơ hội để tạo block;
Tất cả những người khai thác khối đượ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ị sập.
Lịch sử chứng minh rằng việc xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung của các nút xác minh. 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 tính tập trung 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, với hệ số Nakamoto chỉ là 20, thấp hơn nhiều so với Polkadot là 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này được thực hiện 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 128K TPS trên mạng công khai 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ộ trước. Bản 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ị lợi dụng một cách độc hại. Do thiếu cơ chế "phá sản của con bạc", 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 có thể thực hiện tấn công DDoS để ngăn chặn các xác thực viên trung thực, từ đó thay đổi trạng thái.
So với trước, 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, việc tấn công cần phải đặt cược toàn bộ quyền kiểm soát 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 việc kẻ tấn công mất đi số tiền đặt cược.
Avalanche
Avalanche sử dụng kiến trúc mạng chính + mạng con để mở rộng, trong đó 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ý những người xác thực và mạng con).
Mỗi subnet lý thuyết có thể đạt TPS khoảng ~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 lựa chọn tham gia subnet, và subnet có thể đặt ra 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.
Trong Polkadot, tất cả rollup 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 tính 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 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 tầng rollup, thay vì giải quyết vấn đề trực tiếp ở tầng 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 tầng 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à phi tập trung, gặp phải các vấn đề như thiếu an toàn, tách biệt lẫn nhau và độ trễ cao (cần 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 mà mỗi giao dịch có thể xử lý. Nhu cầu tính toán để tạo ra bằng chứng không kiến thức là 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 mỗi lô, điều này có thể gây ra tình trạng tắc nghẽn mạng và tăng giá gas trong thời gian có nhu cầu cao, ả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 2x10^6 lần so với giao thức an ninh kinh tế cốt lõi của Polkadot.
Hơn nữa, vấn đề khả dụng dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm những nhược điểm 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ả 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
Đỉnh điểm 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 hiệu năng bằng sự tập trung, hay đánh đổi hiệu quả bằng sự tin tưởng được thiết lập trước, 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 giấy phép, tầng bảo mật 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 ninh, phân quyền và hiệu suất cao.
Trong bối cảnh ngày nay khi mà việc theo đuổi ứng dụng quy mô lớn hơn đang diễn ra, "mở rộng không cần tin cậy" mà Polkadot kiên trì theo đuổi có thể chính là giải pháp thực sự 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.
19 thích
Phần thưởng
19
5
Đăng lại
Chia sẻ
Bình luận
0/400
NFT_Therapy
· 07-16 00:58
Lại gặp bạn bè cũ dot rồi!
Xem bản gốcTrả lời0
LayerZeroHero
· 07-14 19:38
Thực tế chứng minh chắc chắn có trade-off, vẫn cần chạy benchmark để xác minh...
Kiến trúc Web3 của Polkadot: Sự cân bằng hoàn hảo giữa khả năng mở rộng và an ninh
Sự cân bằng giữa khả năng mở rộng và an ninh: Thiết kế kiến trúc Web3 của Polkadot
Trong bối cảnh công nghệ blockchain không ngừng theo đuổi hiệu suất cao hơn, một vấn đề then chốt dần dần nổi lên: làm thế nào để nâng cao 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 độ công nghệ, mà còn liên quan đến những cân nhắc 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 tốc độ cao nếu đánh đổi bằng sự tin tưởng và an toàn thường khó có thể hỗ trợ những đổ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ố thỏa hiệp trong quá trình theo đuổi thông lượng cao 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 hay khả năng tương tác mạng không? Bài viết này sẽ thảo luận về những câu hỏi này, phân tích sâu sắc các sự lựa chọn và thỏa hiệp của Polkadot trong thiết kế khả năng mở rộng, 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á sự lựa chọn khác nhau của chúng trong ba yếu tố: hiệu suất, an ninh và phân quyền.
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ể gây ra rủi ro tập trung ở một số khía cạnh không? Có khả năng hình thành điểm thất bại duy nhất 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 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 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 thực bởi một core nào đó của chuỗi trung gian, chỉ cần đáp ứng một điều kiện tiên quyết: 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 triển.
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 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 do việc xác thực 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 phép và không cần tin cậy, 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ể lợi dụng điều 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 hại, từ đó giảm tổng công suất và hiệu quả của rollup.
Mục tiêu của Polkadot là duy trì tính linh hoạt của rollup và khai thác hiệu quả tài nguyên của chuỗi tiếp hợp mà không ảnh hưởng đến các đặc tính chính của hệ thống.
Vấn đề tin cậy của Sequencer
Một giải pháp đơn giản là đặt giao thức thành "có giấy phép": chẳng hạn như áp dụng cơ chế danh sách trắng, hoặc tin tưởng mặc định rằng các trình sắp xếp sẽ không có hành vi ác ý, 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ể đư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 giấy 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 chọn là: hoàn toàn giao 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 thực trên lõi Polkadot nào.
Thiết kế này đảm bảo được cả tính linh hoạt và an toàn. Polkadot sẽ thực hiện lại các chuyển đổi trạng thái của rollup trong quy trình khả dụng, và thông qua giao thức kinh tế mã hóa ELVES đảm bảo tính chính xác của phân bổ core.
Trước khi ghi dữ liệu vào lớp khả dụng dữ liệu của Polkadot trong bất kỳ khối rollup nào, một nhóm gồm khoảng 5 người xác thực sẽ kiểm tra tính hợp lệ của nó. Họ nhận các biên bản ứng cử viên và bằng chứng tính hợp lệ từ bộ sắp xếp, trong đó bao gồm khối rollup và bằng chứng lưu trữ tương ứng. Những thông tin này sẽ được chuyển cho chức năng xác thực của chuỗi song song xử lý, và sẽ được các người xác thực trên chuỗi trung gian thực hiện lại.
Kết quả xác thực bao gồm một bộ chọn core, được sử dụng để chỉ định core nào sẽ xác thực khối. Người xác thực sẽ so sánh chỉ mục đó với core mà họ phụ trách; 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 duy trì tính chất không cần tin cậy và không cần sự cho phép, tránh các hành vi độc hại như can thiệp vào vị trí xác thực của bộ sắp xếp, đảm bảo rằng ngay cả khi rollup sử dụng nhiều core cũng có thể duy trì 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ề tính bảo mật. 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.
Nhờ vào giao thức ELVES, Polkadot đã mở rộng tính bảo mật của mình một cách toàn diệ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 đặt bất kỳ giới hạn hoặc 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 tổng quát
Mở rộng linh hoạt sẽ không hạn chế khả năng 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à việc thực hiện một lần hoàn thành trong vòng 2 giây. Nhờ vào việc 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 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 chắc chắn sẽ dẫn đến 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 nhất quán. 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, mà 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ụ:
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à kiểm tra cũng tăng lên đá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 sẽ không ảnh hưởng đến thông lượng truyền tải tin nhắn.
Giao tiếp tin nhắn qua 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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi trung gian đóng vai trò là 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 khả năng mở rộng linh hoạt, tăng cường khả năng mở rộng theo chiều dọc của hệ thống.
Sự đánh đổi của các giao thức khác
Như chúng ta đã biết, việc nâng cao hiệu suất thường phải hy sinh tính phi tập trung và an ninh. 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 hơn, hiệu suất của chúng cũng không đạt yêu cầu.
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 đó sử dụng kiến trúc đơn lớp với khả năng xử lý cao để đạt được khả năng mở rộng, dựa vào chứng minh lịch sử, xử lý song song CPU và cơ chế đồng thuận dựa trên người đứng đầu, lý thuyết TPS 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.
Lịch sử chứng minh rằng việc xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung của các nút xác minh. 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 tính tập trung 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, với hệ số Nakamoto chỉ là 20, thấp hơn nhiều so với Polkadot là 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này được thực hiện 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 128K TPS trên mạng công khai 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ộ trước. Bản 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ị lợi dụng một cách độc hại. Do thiếu cơ chế "phá sản của con bạc", 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 có thể thực hiện tấn công DDoS để ngăn chặn các xác thực viên trung thực, từ đó thay đổi trạng thái.
So với trước, 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, việc tấn công cần phải đặt cược toàn bộ quyền kiểm soát 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 việc kẻ tấn công mất đi số tiền đặt cược.
Avalanche
Avalanche sử dụng kiến trúc mạng chính + mạng con để mở rộng, trong đó 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ý những người xác thực và mạng con).
Mỗi subnet lý thuyết có thể đạt TPS khoảng ~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 lựa chọn tham gia subnet, và subnet có thể đặt ra 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.
Trong Polkadot, tất cả rollup 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 tính 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 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 tầng rollup, thay vì giải quyết vấn đề trực tiếp ở tầng 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 tầng 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à phi tập trung, gặp phải các vấn đề như thiếu an toàn, tách biệt lẫn nhau và độ trễ cao (cần 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 mà mỗi giao dịch có thể xử lý. Nhu cầu tính toán để tạo ra bằng chứng không kiến thức là 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 mỗi lô, điều này có thể gây ra tình trạng tắc nghẽn mạng và tăng giá gas trong thời gian có nhu cầu cao, ả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 2x10^6 lần so với giao thức an ninh kinh tế cốt lõi của Polkadot.
Hơn nữa, vấn đề khả dụng dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm những nhược điểm 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ả 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
Đỉnh điểm 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 hiệu năng bằng sự tập trung, hay đánh đổi hiệu quả bằng sự tin tưởng được thiết lập trước, 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 giấy phép, tầng bảo mật 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 ninh, phân quyền và hiệu suất cao.
Trong bối cảnh ngày nay khi mà việc theo đuổi ứng dụng quy mô lớn hơn đang diễn ra, "mở rộng không cần tin cậy" mà Polkadot kiên trì theo đuổi có thể chính là giải pháp thực sự hỗ trợ cho sự phát triển lâu dài của Web3.