Sự đánh đổi và cân bằng trong khả năng mở rộng Blockchain: Lấy Polkadot làm ví dụ
Trong bối cảnh công nghệ Blockchain ngày càng tìm kiếm hiệu quả cao hơn, một vấn đề then chốt dần dần nổi lên: làm thế nào để mở rộng hiệu suất mà không phải 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, 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ợ cho sự đổi mới thực sự bền vững.
Là một trong những động lực chính cho khả năng mở rộng Web3, Polkadot có phải đã hy sinh một số điều để đạt được 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ề tính phi tập trung, an ninh hoặc khả năng tương tác mạng? Bài viết này sẽ khám phá 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 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, bàn luận về những con đường khác nhau mà chúng chọn giữa hiệu suất, an ninh và tính phi tập trung.
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, liệu điều này có thể mang lại 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ó?
Việc vận hành Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian, và giao tiếp 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 cậy, 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 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 tới.
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 core của Polkadot. Khả năng mới này được giới thiệu thông qua chức 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 minh khối rollup không cố định trên một core nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Vì giao thức nộp khối cho 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ể nộp khối để được xác thực 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ều này để nộp lại các khối hợp pháp đã được xác thực trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó làm 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à 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ư sử 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 năng 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ì phải 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. Mọi người 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, do đó phải rõ ràng trong đầu ra về việc 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 phối 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 Polkadot, 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 bản ứng cử viên và chứng minh tính hợp lệ được nộp bởi bộ sắp xếp, 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 xử lý bởi hàm xác thực chuỗi song song và được thực hiện lại bởi các xác thực viên trên chuỗi trung gian.
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 trên core nào. Người xác minh sẽ so sánh chỉ số đó với core mà họ 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 tính không cần tin cậy và không cần giấy phép, tránh các hành vi xấu như thao túng vị trí xác minh của các bộ sắp xếp, đảm bảo 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 an toàn. An toàn 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 để duy trì tính sống sót.
Nhờ vào giao thức ELVES, Polkadot mở rộng hoàn toàn tính bảo mật của mình đế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 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 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 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 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 việc đưa vào sự phức tạp, đây là cách duy nhất chấp nhận được 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 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ể phụ thuộc 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à kiểm tra cũng tăng lên đá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 thông điệp.
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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi trung gian đóng vai trò là bề mặt kiểm soát, thay vì bề mặt dữ liệu. Cập nhật này sẽ cải thiện 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 thỏa hiệp khác của các giao thức là gì?
Như mọi người đã 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, 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 hoặc Ethereum, mà thực hiện khả năng mở rộng bằng kiến trúc một lớp có khả năng thông lượng cao, 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 lãnh đạo, lý thuyết TPS có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lên 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), phân bổ slot theo lượng đặt cọc;
Càng nhiều phần thưởng, càng nhiều phân phối. Ví dụ, việc đặt cược 1% của 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 đều được công bố trước, điều này làm tăng rủi ro mạng phải đối mặt với các cuộc tấn công DDoS có định hướng và thường xuyên bị ngắt quãng.
Lịch sử chứng minh rằng việc xử lý song song yêu cầu phần cứng cực kỳ cao, dẫn đến sự tập trung của các nút xác thực. Nút có nhiều tiền đặt cọc hơn sẽ 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 trầm trọng thêm sự tập trung, cũng như làm tăng rủi ro hệ thống bị tê liệt sau khi bị tấn công.
Solana hy sinh 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 đượ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ó nguy cơ an ninh: Danh tính của các nút xác thực phân mảnh 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ị lợi dụng một cách ác ý. Do thiếu cơ chế "phá sản của con bạc", kẻ tấn công có thể chờ đợi cho một phân mảnh hoàn toàn nằm trong tay mình, hoặc ngăn chặn các xác thực viên trung thực thông qua tấn công DDoS, từ đó sửa đổ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à công bố 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 phải đặt 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 tiề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 có thể đạt TPS lý thuyết 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 như địa lý, KYC, từ đó hy sinh tính 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 hóa. 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 chắc chắn.
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 trên 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 cao hơn của ngăn xếp.
Optimistic Rollup
Hiện nay, hầu hết các Optimistic rollup đều tập trung (có một số thậm chí chỉ có một sequencer), tồn tại vấn đề về an toàn không đủ, cách biệt lẫn nhau, độ 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 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 chứng minh không biết là rất cao, và cơ chế "người thắng lấy hết" dễ dẫn đến sự tập trung hóa của 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ô, trong thời gian nhu cầu cao sẽ gây ra tắc nghẽn mạng, tăng gas, ả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 cao hơn khoảng 2x10^6 lần so với giao thức an ninh kinh tế mã hóa cốt lõi 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, 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 trao đổi tính trung tâm để lấy hiệu suất, hay trao đổi lòng tin đã được thiết lập để 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 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, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi mà việc áp dụng quy mô lớn đang được theo đuổi, "khả năng mở rộng không cần tin cậy" mà Polkadot kiên định, có thể 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.
Polkadot mở rộng linh hoạt: Tìm kiếm sự cân bằng giữa hiệu suất và Phi tập trung
Sự đánh đổi và cân bằng trong khả năng mở rộng Blockchain: Lấy Polkadot làm ví dụ
Trong bối cảnh công nghệ Blockchain ngày càng tìm kiếm hiệu quả cao hơn, một vấn đề then chốt dần dần nổi lên: làm thế nào để mở rộng hiệu suất mà không phải 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, 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ợ cho sự đổi mới thực sự bền vững.
Là một trong những động lực chính cho khả năng mở rộng Web3, Polkadot có phải đã hy sinh một số điều để đạt được 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ề tính phi tập trung, an ninh hoặc khả năng tương tác mạng? Bài viết này sẽ khám phá 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 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, bàn luận về những con đường khác nhau mà chúng chọn giữa hiệu suất, an ninh và tính phi tập trung.
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, liệu điều này có thể mang lại 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ó?
Việc vận hành Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian, và giao tiếp 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 cậy, 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 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 tới.
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 core của Polkadot. Khả năng mới này được giới thiệu thông qua chức 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 minh khối rollup không cố định trên một core nào, điều này có thể ảnh hưởng đến tính linh hoạt của nó.
Vì giao thức nộp khối cho 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ể nộp khối để được xác thực 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ều này để nộp lại các khối hợp pháp đã được xác thực trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó làm 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à 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ư sử 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 năng 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ì phải 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. Mọi người 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, do đó phải rõ ràng trong đầu ra về việc 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 phối 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 Polkadot, 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 bản ứng cử viên và chứng minh tính hợp lệ được nộp bởi bộ sắp xếp, 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 xử lý bởi hàm xác thực chuỗi song song và được thực hiện lại bởi các xác thực viên trên chuỗi trung gian.
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 trên core nào. Người xác minh sẽ so sánh chỉ số đó với core mà họ 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 tính không cần tin cậy và không cần giấy phép, tránh các hành vi xấu như thao túng vị trí xác minh của các bộ sắp xếp, đảm bảo 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 an toàn. An toàn 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 để duy trì tính sống sót.
Nhờ vào giao thức ELVES, Polkadot mở rộng hoàn toàn tính bảo mật của mình đế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 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 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 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 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 việc đưa vào sự phức tạp, đây là cách duy nhất chấp nhận được 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 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ể phụ thuộc 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à kiểm tra cũng tăng lên đá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 thông điệp.
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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi trung gian đóng vai trò là bề mặt kiểm soát, thay vì bề mặt dữ liệu. Cập nhật này sẽ cải thiện 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 thỏa hiệp khác của các giao thức là gì?
Như mọi người đã 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, 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 hoặc Ethereum, mà thực hiện khả năng mở rộng bằng kiến trúc một lớp có khả năng thông lượng cao, 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 lãnh đạo, lý thuyết TPS có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lên 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), phân bổ slot theo lượng đặt cọc;
Càng nhiều phần thưởng, càng nhiều phân phối. Ví dụ, việc đặt cược 1% của 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 đều được công bố trước, điều này làm tăng rủi ro mạng phải đối mặt với các cuộc tấn công DDoS có định hướng và thường xuyên bị ngắt quãng.
Lịch sử chứng minh rằng việc xử lý song song yêu cầu phần cứng cực kỳ cao, dẫn đến sự tập trung của các nút xác thực. Nút có nhiều tiền đặt cọc hơn sẽ 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 trầm trọng thêm sự tập trung, cũng như làm tăng rủi ro hệ thống bị tê liệt sau khi bị tấn công.
Solana hy sinh 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 đượ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ó nguy cơ an ninh: Danh tính của các nút xác thực phân mảnh 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ị lợi dụng một cách ác ý. Do thiếu cơ chế "phá sản của con bạc", kẻ tấn công có thể chờ đợi cho một phân mảnh hoàn toàn nằm trong tay mình, hoặc ngăn chặn các xác thực viên trung thực thông qua tấn công DDoS, từ đó sửa đổ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à công bố 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 phải đặt 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 tiề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 có thể đạt TPS lý thuyết 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 như địa lý, KYC, từ đó hy sinh tính 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 hóa. 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 chắc chắn.
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 trên 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 cao hơn của ngăn xếp.
Optimistic Rollup
Hiện nay, hầu hết các Optimistic rollup đều tập trung (có một số thậm chí chỉ có một sequencer), tồn tại vấn đề về an toàn không đủ, cách biệt lẫn nhau, độ 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 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 chứng minh không biết là rất cao, và cơ chế "người thắng lấy hết" dễ dẫn đến sự tập trung hóa của 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ô, trong thời gian nhu cầu cao sẽ gây ra tắc nghẽn mạng, tăng gas, ả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 cao hơn khoảng 2x10^6 lần so với giao thức an ninh kinh tế mã hóa cốt lõi 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, 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 trao đổi tính trung tâm để lấy hiệu suất, hay trao đổi lòng tin đã được thiết lập để 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 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, phi tập trung và hiệu suất cao.
Trong bối cảnh hiện nay khi mà việc áp dụng quy mô lớn đang được theo đuổi, "khả năng mở rộng không cần tin cậy" mà Polkadot kiên định, có thể 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.