Quyết định mở rộng: Sự cân nhắc giữa Polkadot và Web3

Trong bối cảnh blockchain ngày càng theo đuổi hiệu suất cao hơn, một vấn đề then chốt dần hiện rõ: làm thế nào để mở rộng hiệu suất mà không hy sinh tính an toàn và sự 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à 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 cơ sở hy sinh niềm tin và tính an toàn, thường khó có thể hỗ trợ đổi mới thực sự bền vững.

Là một trong những động lực quan trọng cho khả năng mở rộng Web3, liệu Polkadot có phải đã hy sinh điều gì đó dưới mục tiêu có khả năng 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 quyền, an ninh hoặc khả năng tương tác mạng không?

Bài viết này sẽ xoay quanh những vấn đề này, phân tích sâu sắc sự nhượng bộ và thỏa hiệp 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 trung gian tập trung, đ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? Liệu có thể hình thành điểm lỗi đơn lẻ hoặc kiểm soát, từ đó ảnh hưởng đến đặc tính phi tập trung của nó?

Việc thực thi Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian kết nối, và 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 yêu cầu giấy phép, không cần tin cậy, bất cứ 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 minh bởi một core nào đó của chuỗi trung gian, chỉ cần 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 lên.

Sự cân nhắc trong việc mở rộng theo chiều dọc

Rollup có thể đạt được sự 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 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 xác thực khối rollup không cố định thực hiện 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 gửi khối đến chuỗi trung gian là không cần sự cho phép và không cần tin tưởng, 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 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 tài nguyên một cách độc hại, từ đó giảm tổng nă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à việc 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 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à 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 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 thiết kế của Polkadot, chúng ta không thể có bất kỳ giả định nào về độ tin cậy của sequencer, vì để duy trì tính chất "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 được chọn cho Polkadot 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 đáng tin cậy duy nhất cho tất cả thông tin đồng thuận, do đó phải tuyên bố rõ ràng trong đầu ra nên thực hiện xác minh trên Polkadot core nào.

Thiết kế này đảm bảo cả tính linh hoạt và an ninh. Polkadot sẽ thực hiện lại các chuyển đổ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 ghi dữ liệu vào lớp khả dụng của Polkadot trong bất kỳ khối rollup nào, một nhóm gồm khoảng 5 người xác thực sẽ trước tiên xác minh tính hợp pháp của nó. 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 nộp, trong đó bao gồm khối rollup và các chứng minh lưu trữ tương ứng. Thông tin này sẽ được xử lý bởi hàm xác thực của chuỗi song song, và được các người xác thực trên chuỗi tiếp hợp thực thi lại.

Kết quả kiểm tra bao gồm một bộ chọn core, được sử dụng để chỉ định block nên được xác thực trên core nào. Người xác thực sẽ so sánh chỉ số đó với core mà họ chịu trách nhiệm; nếu không一致, block đó sẽ bị loại bỏ.

Cơ chế này đảm bảo hệ thống luôn giữ được tính chất không cần tin cậy và không cần cấp phép, tránh các hành vi độc hại như thao túng vị trí xác thực của bộ sắp xếp, đảm bảo ngay cả khi rollup sử dụng nhiều core vẫn 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 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ì tính sống còn.

Thông qua 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 tính 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 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 hạn chế tính 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 hoàn chỉnh 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 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ẽ đưa ra sự phức tạp, đây là cách duy nhất có thể 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 động thông qua giao diện Agile Coretime, nhằm duy trì mức độ an toàn nhất quán. Chúng cũng cần đáp ứng một phần yêu cầu RFC103 để thích ứng 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, 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 cố định của core, hoặc điều chỉnh thủ công qua chuỗi bên ngoài;
• Chiến lược nhẹ: Giám sát tải giao dịch cụ thể trong mempool của nút;
• Chiến lược tự động hóa: Gọi 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 tin.

Giao tiếp tin nhắn giữa các rollup được thực hiện bởi lớp truyền tải bên dưới, không gian khối giao tiếp của mỗi rollup là cố định và không liên quan đến số 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 hoạt động như mặt kiểm soát 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ă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 tăng hiệu suất thường phải đánh đổi bằng sự phi tập trung và an ninh. Nhưng theo 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 được như mong muốn.

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 đơn lớp có khả năng thông lượng cao, dựa vào chứng minh lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, lý thuyết TPS có thể đạt 65.000.

Một thiết kế quan trọng là cơ chế lập lịch lãnh đạo đã được công khai và có thể xác minh trước.

• Mỗi epoch( khoảng hai ngày hoặc 432,000 slot) bắt đầu, phân bổ slot theo lượng staking;
• Càng nhiều đặt cọc, càng nhiều phân bổ. Ví dụ, đặt cọc 1% người xác thực sẽ nhận được khoảng 1% cơ hội tạo khối;
• Tất cả các thợ đào đều công bố trước, làm tăng rủi ro mạng gặp phải các cuộc tấn công DDoS có định hướng và thường xuyên bị ngừng hoạt động.

PoH và xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung hóa của các nút xác thực. Các nút có nhiều staking hơn có cơ hội tạo block lớn hơn, các nút nhỏ hầu như không có slot, làm trầm trọng thêm sự tập trung hóa, cũng như 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à 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 cộng phi tập trung.

Cơ chế đồng thuận của TON có tồn tại rủi ro về an ninh: danh tính của các nút xác thực phân mảnh có thể bị lộ trước. Tài liệu trắng của TON cũng chỉ rõ, đ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ế "người chơi phá sản", kẻ tấn công có thể chờ đợi một phân mảnh nào đó hoàn toàn nằm trong tầm kiểm soát của họ, hoặc ngăn chặn các nút xác thực trung thực thông qua tấn công DDoS, từ đó làm sai lệch 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 các người xác thực, cuộc tấn công cần phải cược toàn bộ quyền kiểm soát để 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ố 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 chuyển khoản X-Chain(, ~4.500 TPS), hợp đồng thông minh C-Chain(, ~100-200 TPS), và 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 tới ~5,000, tương tự như tư duy 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 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 sự phân cấp và an ninh.

Trong 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 ở 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 giao vấn đề lên tầng trên của ngăn xếp.

Optimistic Rollup

Hiện tại hầu hết các Optimistic rollup đều tập trung (, một số thậm chí chỉ có một sequencer ), dẫn đến các vấn đề như thiếu an ninh, cô lập lẫn nhau, độ trễ cao ( cần phải chờ đợi 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ị hạn chế bởi khối lượng dữ liệu có thể xử lý cho một giao dịch duy nhất. 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 thắng được tất cả" 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 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 gas trong những thời điểm có 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 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ả dụng dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm những hạn chế của nó. Để đảm bảo bất kỳ ai cũng có thể xác minh giao dịch, vẫn cần cung cấp dữ liệu giao dịch đầy đủ. Điều này thường phụ thuộc vào các giải pháp khả dụng dữ liệu bổ sung, làm tăng chi phí và phí người dùng.

Kết luận

Đỉnh cao 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 tập trung hóa để đổi lấy hiệu suất, hay đặt niềm tin trước để đạt được 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 sự cho phép, một 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 bảo mật, 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 áp dụng quy mô lớn hơn, "mở rộng không tin cậy" mà Polkadot kiên trì theo đuổi có lẽ chính là giải pháp thực sự có thể hỗ trợ sự phát triển bền vững của Web3.