Sự cân nhắc về khả năng mở rộng: Lựa chọn Polkadot và Web3

Trong bối cảnh công nghệ blockchain đang không ngừng theo đuổi việc nâng cao hiệu suất, một vấn đề then chốt dần dần nổi lên: làm thế nào để nâng cao 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 độ kỹ thuật, 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 cơ sở hy sinh niềm tin và an toàn, thường khó có thể hỗ trợ sự đổ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ó thực hiện một số sự thỏa hiệp nào trong quá trình theo đuổi thông lượng cao và độ trễ thấp? Mô hình rollup của nó có đang nhượng bộ về tính phi tập trung, an ninh hay khả năng tương tác giữa các mạng không? Bài viết này sẽ đi sâu phân tích những sự lựa chọn và thỏa hiệp trong thiết kế khả năng mở rộng của Polkadot, so sánh với các giải pháp của các chuỗi công khai chính khác, và thảo luận về những lựa chọn khác nhau của chúng trong ba yếu tố: hiệu suất, an ninh và tính 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, liệu điều này có thể mang lại rủi ro tập trung trong một số khía cạnh không? Liệu có khả năng hình thành điểm thất bạ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 chạy Rollup phụ thuộc vào bộ sắp xếp 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 giấy 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 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 đá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 lên.

Sự đánh đổi của việc 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 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ế, nhận thấy rằng việc xác minh 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ó.

Do vì giao thức gửi khối tới chuỗi trung gian là không cần giấy phép và không cần tin cậy, bất kỳ ai cũng có thể gửi khối để xác minh 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 để gửi lại nhiều lần 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ể 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à việc sử dụng hiệu quả tài nguyên của chuỗi tiếp nối 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 tưởng các trình sắp xếp không có hành vi ác ý, từ đó đảm bảo tính khả dụng 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ề sequencer, vì cần duy trì các đặc tính "không cần tin cậy" và "không cần cấp 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à: 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 rõ ràng trong đầu ra về việc nên thực hiện xác minh trên lõi Polkadot nào.

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

Kết quả xác minh bao gồm một bộ chọn core, đượ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 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ì các 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 minh, đảm bảo ngay cả khi rollup sử dụng nhiều core cũng có thể duy trì tính đàn hồi.

An toàn

Trong quá trình theo đuổi khả năng mở rộng, Polkadot không thỏa hiệp về mặt an toàn. 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.

Bằng cách sử dụng 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 tính trên core mà không cần hạn chế hoặc giả định nào về số lượng core được sử dụng.

Do đó, 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 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 đầ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

Khả năng xử lý cao hơn và độ trễ thấp hơn không thể tránh khỏi đã dẫn đến sự phức tạp, đây là cách cân bằng 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 để 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, 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: 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í triển khai và kiểm tra cũng tăng đá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 mở rộng linh hoạt sẽ 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 lớp truyền tải cơ sở, không gian khối truyền thông 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 cũng sẽ hỗ trợ truyền tải tin nhắn ngoài chuỗi, với chuỗi trung gian làm mặt điều khiển, chứ không phải 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 thỏa hiệp nào?

Như đã biết, việc cải thiện hiệu suất thường phải đánh đổi bằng sự phi tập trung và tính an toàn. 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 đượ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à thay vào đó là 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 bằng chứng lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên người 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 staking;

• Càng nhiều đặt cược, càng nhiều phân bổ. Ví dụ, một người xác thực đặt cược 1% sẽ có khoảng 1% cơ hội tạo khối;

• Tất cả các thợ đào đượ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 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 việc các nút xác thực tập trung hóa. Các nút có nhiều tài sản thế chấp càng 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, làm gia tăng sự tập trung hóa và cũng 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 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 mảnh sẽ bị lộ trước. Tài liệu 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 con bạc", kẻ tấn công có thể chờ đợi một phân mảnh nào đó bị kiểm soát hoàn toàn, hoặc thông qua các cuộc tấn công DDoS để ngăn chặn các nút xác thực trung thực, từ đó làm thay đổi trạng thái.

So với trước, những người xác thực của Polkadot được phân bổ ngẫu nhiên và công khai muộn, kẻ tấn công không thể biết trước danh tính của những người xác thực, để tấn công cần 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à khiến kẻ tấn công mất đi khoản đặt cọc.

Avalanche

Avalanche sử dụng kiến trúc mạng chính + mạng phụ để mở rộng, 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ý các xác nhận viên và mạng phụ).

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 chọn tham gia vào các subnet, và các subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi giữa tính phi tập trung và an toàn.

Trong Polkadot, tất cả các rollup đều chia sẻ bảo mật 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 toàn, vẫ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 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 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 là tập trung, có vấn đề về độ an toàn không đủ, cách biệt 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 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 chứng minh không kiến thức là rất cao, và cơ chế "người thắng 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 khối lượng giao dịch trong mỗi đợt, dẫn đến 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 chi phí của giao thức an ninh kinh tế cốt lõi của Polkadot.

Ngoài ra, vấn đề tính khả dụng của dữ liệu 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 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 tính 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

Điểm kết thúc 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 đổi trung tâm hóa lấy hiệu suất, hay đổi sự tin cậy được thiết lập trước lấy hiệu quả, mà 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 việc theo đuổi việc triển khai ứng dụng quy mô lớn hơn ngày nay, "mở rộng không tin cậy" mà Polkadot kiên trì, có lẽ mới thực sự là giải pháp có thể hỗ trợ sự phát triển lâu dài của Web3.