Sự cân nhắc về khả năng mở rộng của Blockchain: Khám phá Polkadot và hệ sinh thái Web3
Trong bối cảnh Blockchain ngày càng tìm kiếm hiệu suất cao hơn, một vấn đề then chốt dần dần hiện ra: Làm thế nào để mở rộng hiệu suất mà không đánh đổi an ninh và tính linh hoạt của hệ thống?
Đây không chỉ là thách thức về mặt kỹ thuật, mà còn là sự lựa chọn sâu sắc trong thiết kế kiến trúc. Đặc biệt đố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à an ninh, thường 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, liệu Polkadot đã phải hy sinh một số điều gì dưới mục tiêu thông lượng cao và độ trễ thấp? Mô hình rollup của nó có phải đã nhượng bộ về phân cấp, 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 sự lựa chọn và cân nhắc 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á những lựa chọn khác nhau của chúng trong ba yếu tố: 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 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 (Relay Chain), điều này có thể tạo ra rủi ro tập trung ở một số khía cạnh không? Liệu có khả năng hình thành điểm lỗi đơn hoặc kiểm soát, từ đó ảnh hưởng đến 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 (sequencer) của chuỗi trung gian kết nối, giao tiếp của nó sử dụng một cơ chế được gọi là 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: 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.
Thương lượng mở rộng theo chiều dọc
Rollup có thể đạt được mở rộng 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 qua tính năng "Mở rộng Linh hoạt" (Elastic Scaling). Trong quá trình thiết kế, chúng tôi nhận thấy rằng việc xác minh khối rollup không bị cố định thực hiện trên một core nào đó có thể ảnh hưởng đến tính linh hoạt của nó.
Do vì giao thức gửi khối tới chuỗi trung gian là không cần cấp phép và không cần tin tưởng, bất kỳ ai cũng có thể gửi khối tới 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 đó tới 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ô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à sử dụng hiệu quả tài nguyên của chuỗi trung gian mà không ảnh hưởng đến các đặc điểm chính 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": chẳng hạn như áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng các 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ể đưa ra bất kỳ giả định tin cậy nào về sequencer, vì cần duy trì đặ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 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 đáng tin cậy duy nhất, vì vậy phải rõ ràng tuyên bố 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 đạt được sự đảm bảo kép về 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à đả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 (DA) của Polkadot, một nhóm gồ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 bản ứng cử (candidate receipt) và chứng minh tính hợp lệ (PoV) do bộ sắp xếp gửi, trong đó chứa khối rollup và các chứng minh lưu trữ tương ứng. Những thông tin này sẽ được xử lý bởi chức năng xác thực của các chuỗi song song, được thực hiện lại bởi những người xác thực trên chuỗi trung gian.
Kết quả xác minh chứa một core selector, được sử dụng để chỉ định nên xác minh khối trên core nào. Người xác minh sẽ so sánh chỉ mục đó với core mà mình phụ trách; nếu không khớp, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo hệ thống luôn duy trì thuộc tính không cần tin cậy và không cần phép, tránh hành vi xấu từ các tác nhân như bộ sắp xếp thao túng vị trí xác thực, đảm bảo ngay cả khi rollup sử dụng nhiều core vẫn 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ề 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.
Nhờ vào 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 giới hạn hoặc giả định nào về số lượng core được sử dụng.
Vì vậy, 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.
Tính linh hoạ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 mở rộng linh hoạt, tổng 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 không thể tránh khỏi việc giới thiệu 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 linh hoạt 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 của RFC103 để phù hợp với các tình huống 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 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: Thông qua dữ liệu lịch sử và giao diện XCM để gọi trước dịch vụ coretime cấu hình tài nguyên.
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 đá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 sẽ không ảnh hưởng đến thông lượng truyền tải tin nhắn.
Thông tin liên lạc 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 thông tin của mỗi rollup là cố định và 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 tin ngoài chuỗi (off-chain messaging), với chuỗi trung gian làm bề mặt điều khiển, chứ không phải bề 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.
Các giao thức khác đã thực hiện những nhượng bộ nào?
Như mọi người đều biết, việc cải thiện hiệu suất thường phải trả giá bằng cách 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ạnh tranh của Polkadot có mức độ phi tập trung thấp, hiệu suất của chúng cũng không đáng 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 đó đạt được khả năng mở rộng thông qua kiến trúc đơn lớp có khả năng thông lượng cao, dựa vào bằng chứng lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế phân bổ 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 tài sản được đặt cọc, phân phối càng nhiều. Ví dụ, nếu đặt cọc 1% cho người xác thực, 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 định hướng và thường xuyên ngừng hoạt động.
PoH và xử lý song song có yêu cầu phần cứng rất cao, dẫn đến việc các nút xác thực bị tập trung hóa. Các nút có nhiều tài sản được đặt cọc thì có cơ hội tạo khối lớn hơn, trong khi các nút nhỏ hầu như không có slot, làm trầm trọng thêm tình trạng tập trung hóa và 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 Polkadot là 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này đạt được trong 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ó 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ộ ra sớm. Sách trắng của TON cũng chỉ rõ, 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 ý. Do thiếu cơ chế "phá sản của người đánh bạc", kẻ tấn công có thể chờ một phân đoạn bị kiểm soát hoàn toàn, hoặc ngăn chặn các xác thực viên trung thực thông qua cuộc tấn công DDoS, từ đó thao túng trạng thái.
So với đó, các 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 các xác thực, cuộc tấn công cần phải cược toàn bộ để kiểm soát thành công, chỉ cần có một xác thực trung thực khởi xướng tranh cãi, cuộc tấn công sẽ thất bại và dẫn đến việc kẻ tấn công mất tiền đặt cọc.
Avalanche
Avalanche采用主网+子网架构进行扩展，主网由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 nhận viên và subnet）组成.
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. Nhưng Avalanche cho phép các validator tự do chọn tham gia vào subnet, và subnet có thể thiết lập các yêu cầu bổ sung như địa lý, KYC, hy sinh tính phi tập trung và an ninh.
Tại Polkadot, tất cả cá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 an ninh, 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 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 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 vấn đề thiếu an toàn, cô lập lẫn nhau, độ trễ cao (cần chờ thời gian chứng minh gian lận, thường mất vài ngày).
ZK Rollup
Việc triển khai ZK rollup bị hạn chế bởi lượng dữ liệu có thể xử lý cho mỗi giao dịch. Nhu cầu tính toán để sinh ra bằng chứng không tri thức là 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 số lượng giao dịch trong mỗi lô, điều này có thể gây ra tắc nghẽn mạng và tăng giá gas trong thời gian nhu cầu cao, ả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 chỉnh Turing khoảng gấp 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ó 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 rằng bất kỳ ai cũng có thể xác minh giao dịch, vẫn cần phải 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í người dùng.
Kết luận
Điểm tận 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 thay thế hiệu suất bằng tính tập trung, hay thay thế hiệu quả bằng sự tin tưởng được thiết lập trước, mà thay vào đó thông qua mở rộng linh hoạt, thiết kế giao thức không cần sự cho 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, đã đạt được sự cân bằng đa chiều giữa tính an toàn, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi đang 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 định, có thể là giải pháp thực sự 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.
14 thích
Phần thưởng
14
5
Chia sẻ
Bình luận
0/400
SignatureCollector
· 07-30 01:18
Điểm chuỗi xông lên nào, nhanh tăng lên nhanh tăng lên!
Xem bản gốcTrả lời0
ForumMiningMaster
· 07-30 01:15
Thu nhập mười vạn mỗi tháng chỉ nhờ mấy chuỗi này.
Mở rộng linh hoạt của Polkadot: Con đường hiệu suất cao Web3 không cần phải hy sinh
Sự cân nhắc về khả năng mở rộng của Blockchain: Khám phá Polkadot và hệ sinh thái Web3
Trong bối cảnh Blockchain ngày càng tìm kiếm hiệu suất cao hơn, một vấn đề then chốt dần dần hiện ra: Làm thế nào để mở rộng hiệu suất mà không đánh đổi an ninh và tính linh hoạt của hệ thống?
Đây không chỉ là thách thức về mặt kỹ thuật, mà còn là sự lựa chọn sâu sắc trong thiết kế kiến trúc. Đặc biệt đố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à an ninh, thường 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, liệu Polkadot đã phải hy sinh một số điều gì dưới mục tiêu thông lượng cao và độ trễ thấp? Mô hình rollup của nó có phải đã nhượng bộ về phân cấp, 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 sự lựa chọn và cân nhắc 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á những lựa chọn khác nhau của chúng trong ba yếu tố: 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 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 (Relay Chain), điều này có thể tạo ra rủi ro tập trung ở một số khía cạnh không? Liệu có khả năng hình thành điểm lỗi đơn hoặc kiểm soát, từ đó ảnh hưởng đến 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 (sequencer) của chuỗi trung gian kết nối, giao tiếp của nó sử dụng một cơ chế được gọi là 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: 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.
Thương lượng mở rộng theo chiều dọc
Rollup có thể đạt được mở rộng 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 qua tính năng "Mở rộng Linh hoạt" (Elastic Scaling). Trong quá trình thiết kế, chúng tôi nhận thấy rằng việc xác minh khối rollup không bị cố định thực hiện trên một core nào đó có thể ảnh hưởng đến tính linh hoạt của nó.
Do vì giao thức gửi khối tới chuỗi trung gian là không cần cấp phép và không cần tin tưởng, bất kỳ ai cũng có thể gửi khối tới 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 đó tới 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ô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à sử dụng hiệu quả tài nguyên của chuỗi trung gian mà không ảnh hưởng đến các đặc điểm chính 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": chẳng hạn như áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng các 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ể đưa ra bất kỳ giả định tin cậy nào về sequencer, vì cần duy trì đặ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 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 đáng tin cậy duy nhất, vì vậy phải rõ ràng tuyên bố 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 đạt được sự đảm bảo kép về 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à đả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 (DA) của Polkadot, một nhóm gồ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 bản ứng cử (candidate receipt) và chứng minh tính hợp lệ (PoV) do bộ sắp xếp gửi, trong đó chứa khối rollup và các chứng minh lưu trữ tương ứng. Những thông tin này sẽ được xử lý bởi chức năng xác thực của các chuỗi song song, được thực hiện lại bởi những người xác thực trên chuỗi trung gian.
Kết quả xác minh chứa một core selector, được sử dụng để chỉ định nên xác minh khối trên core nào. Người xác minh sẽ so sánh chỉ mục đó với core mà mình phụ trách; nếu không khớp, khối đó sẽ bị loại bỏ.
Cơ chế này đảm bảo hệ thống luôn duy trì thuộc tính không cần tin cậy và không cần phép, tránh hành vi xấu từ các tác nhân như bộ sắp xếp thao túng vị trí xác thực, đảm bảo ngay cả khi rollup sử dụng nhiều core vẫn 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ề 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.
Nhờ vào 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 giới hạn hoặc giả định nào về số lượng core được sử dụng.
Vì vậy, 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.
Tính linh hoạ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 mở rộng linh hoạt, tổng 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 không thể tránh khỏi việc giới thiệu 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 linh hoạt 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 của RFC103 để phù hợp với các tình huống 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 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: Thông qua dữ liệu lịch sử và giao diện XCM để gọi trước dịch vụ coretime cấu hình tài nguyên.
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 đá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 sẽ không ảnh hưởng đến thông lượng truyền tải tin nhắn.
Thông tin liên lạc 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 thông tin của mỗi rollup là cố định và 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 tin ngoài chuỗi (off-chain messaging), với chuỗi trung gian làm bề mặt điều khiển, chứ không phải bề 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.
Các giao thức khác đã thực hiện những nhượng bộ nào?
Như mọi người đều biết, việc cải thiện hiệu suất thường phải trả giá bằng cách 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ạnh tranh của Polkadot có mức độ phi tập trung thấp, hiệu suất của chúng cũng không đáng 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 đó đạt được khả năng mở rộng thông qua kiến trúc đơn lớp có khả năng thông lượng cao, dựa vào bằng chứng lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế phân bổ 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 tài sản được đặt cọc, phân phối càng nhiều. Ví dụ, nếu đặt cọc 1% cho người xác thực, 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 định hướng và thường xuyên ngừng hoạt động.
PoH và xử lý song song có yêu cầu phần cứng rất cao, dẫn đến việc các nút xác thực bị tập trung hóa. Các nút có nhiều tài sản được đặt cọc thì có cơ hội tạo khối lớn hơn, trong khi các nút nhỏ hầu như không có slot, làm trầm trọng thêm tình trạng tập trung hóa và 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 Polkadot là 172.
TON
TON tuyên bố TPS có thể đạt 104,715, nhưng con số này đạt được trong 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ó 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ộ ra sớm. Sách trắng của TON cũng chỉ rõ, 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 ý. Do thiếu cơ chế "phá sản của người đánh bạc", kẻ tấn công có thể chờ một phân đoạn bị kiểm soát hoàn toàn, hoặc ngăn chặn các xác thực viên trung thực thông qua cuộc tấn công DDoS, từ đó thao túng trạng thái.
So với đó, các 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 các xác thực, cuộc tấn công cần phải cược toàn bộ để kiểm soát thành công, chỉ cần có một xác thực trung thực khởi xướng tranh cãi, cuộc tấn công sẽ thất bại và dẫn đến việc kẻ tấn công mất tiền đặt cọc.
Avalanche
Avalanche采用主网+子网架构进行扩展，主网由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 nhận viên và subnet）组成.
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. Nhưng Avalanche cho phép các validator tự do chọn tham gia vào subnet, và subnet có thể thiết lập các yêu cầu bổ sung như địa lý, KYC, hy sinh tính phi tập trung và an ninh.
Tại Polkadot, tất cả cá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 an ninh, 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 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 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 vấn đề thiếu an toàn, cô lập lẫn nhau, độ trễ cao (cần chờ thời gian chứng minh gian lận, thường mất vài ngày).
ZK Rollup
Việc triển khai ZK rollup bị hạn chế bởi lượng dữ liệu có thể xử lý cho mỗi giao dịch. Nhu cầu tính toán để sinh ra bằng chứng không tri thức là 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 số lượng giao dịch trong mỗi lô, điều này có thể gây ra tắc nghẽn mạng và tăng giá gas trong thời gian nhu cầu cao, ả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 chỉnh Turing khoảng gấp 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ó 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 rằng bất kỳ ai cũng có thể xác minh giao dịch, vẫn cần phải 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í người dùng.
Kết luận
Điểm tận 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 thay thế hiệu suất bằng tính tập trung, hay thay thế hiệu quả bằng sự tin tưởng được thiết lập trước, mà thay vào đó thông qua mở rộng linh hoạt, thiết kế giao thức không cần sự cho 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, đã đạt được sự cân bằng đa chiều giữa tính an toàn, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi đang 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 định, có thể là giải pháp thực sự hỗ trợ sự phát triển lâu dài của Web3.