Sự cân bằng và thách thức của tính mở rộng Blockchain: Giải pháp 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 hiện rõ: làm thế nào để nâng cao hiệu suất mà không hy sinh tính an toàn và độ 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à tính an toàn thì thường khó có thể hỗ trợ đổi mới thực sự bền vững.

Polkadot như một động lực quan trọng cho khả năng mở rộng Web3, liệu mô hình rollup của nó có phải là một sự nhượng bộ về phân cấp, an toàn hoặc khả năng tương tác mạng không? Bài viết này sẽ phân tích sâu sắc những sự đánh đổi và cân nhắc của Polkadot trong thiết kế khả năng mở rộng, đồng thời so sánh với các giải pháp của những blockchain 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à phân cấp.

Thách thức đối với 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 (Relay Chain), điều này có thể mang lại rủi ro tập trung trong một số khía cạnh. Việc vận hành Rollup phụ thuộc vào bộ sắp xếp (sequencer) kết nối với chuỗi trung gian, giao tiếp 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 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 trạng thái của rollup.

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 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 bởi chức năng "Mở rộng Linh hoạt" (Elastic Scaling). Tuy nhiên, do việc xác thực khối rollup không bị cố định 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ó. 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 thực trước đó đến các lõi 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.

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 bộ sắp xếp sẽ không hành động độc hại. Tuy nhiên, trong triết lý thiết kế của Polkadot, không thể có bất kỳ giả định nào về sự tin tưởng đối với sequencer, vì cần duy trì các đặc tính "không cần tin tưởng" và "không cần giấy phép" của hệ thống.

Giải pháp của Polkadot

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 tin cậy duy nhất cho tất cả thông tin đồng thuận, phải được tuyên bố rõ ràng trong đầu ra là nên thực hiện xác minh trên core Polkadot nào.

Thiết kế này đảm bảo bảo mật và tính linh hoạt đồng thời. Polkadot sẽ thực hiện lại chuyển 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ẽ 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ệ được gửi bởi bộ sắp xếp, trong đó chứa 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 minh của chuỗi song song, do 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 core selector, dùng để chỉ định nên xác thực khối trên core nào. Người xác thực sẽ so sánh chỉ số đó với core mà mình 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ì thuộc tính không cần tin cậy và không cần cho phép, tránh hành vi xấu từ những kẻ thao túng như 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ề mặt an ninh. Bảo mật 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 còn. 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 thực tất cả các tính toán trên core, mà không cần phải đặt bất kỳ giới hạn hay giả định nào về số lượng core được sử dụng.

Tính linh hoạt

Mở rộng linh hoạt sẽ không giới hạn 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 hoàn chỉnh trong môi trường WebAssembly, chỉ cần một lần thực thi 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 sẽ không thể tránh khỏi việc giới thiệu sự phức tạp, đây là cách thỏa hiệp 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 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 để thích ứng 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 tin nhắn. Giao tiếp tin nhắn giữa các rollup được thực hiện bởi lớp truyền tải cơ sở, và 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 tin ngoài chuỗi, với chuỗi trung gian làm mặt kiểm soát thay vì mặt dữ liệu. Bản nâng cấp 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.

Sự cân bằng của các giao thức khác

Như mọi người đã biết, việc nâng cao hiệu suất thường phải đánh đổi bằng sự 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, thì hiệu suất của chúng cũng không như mong đợi.

Solana

Solana áp dụng kiến trúc một lớp có khả năng xử lý cao để đạt được khả năng mở rộng, 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 người lãnh đạo, lý thuyết TPS có thể đạt 65,000. Thiết kế chính của nó là cơ chế lập lịch lãnh đạo được công khai và có thể xác minh trước.

Tuy nhiên, 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 đặt cọc nhiều 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 gia tăng sự tập trung hóa và tăng rủi ro hệ thống bị sập sau khi bị tấn công. Solana vì theo đuổi TPS, đã hy sinh sự phi tập trung và khả năng chống tấn công, với hệ số Nakamoto chỉ là 20, thấp hơn nhiều so với 172 của Polkadot.

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 được 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ỉ rõ 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 một phân đoạn hoàn toàn nằm dưới sự kiểm soát của hắn, hoặc thông qua 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 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 người xác thực, cuộc tấn công cần phải 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 phụ để 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ý người xác thực và mạng phụ). Mỗi mạng phụ có thể đạt TPS lý thuyết lên đến ~5,000, tương tự như ý tưởng của Polkadot: giảm tải của từng khối để đạt được khả năng mở rộng.

Nhưng Avalanche cho phép các xác thực viên 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 như địa lý, KYC, hy sinh sự phi tập trung và an ninh. Trong 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 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 một lớp cao hơn trong ngăn xếp.

Optimistic Rollup hiện tại hầu hết đều là tập trung, tồn tại vấn đề an ninh không đủ, cách ly lẫn nhau, độ trễ cao (cần chờ thời gian chứng minh gian lận, thường là vài ngày).

Việc thực hiện ZK Rollup bị giới hạn bởi khối lượng dữ liệu có thể xử lý trong một giao dịch. Nhu cầu tính toán để tạo ra bằng chứng không kiến thức rất cao, và cơ chế "người thắng được 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 người dùng.

So với, chi phí của ZK rollup đầy đủ Turing khoảng gấp 2x10^6 lần so với giao thức bảo mật kinh tế cốt lõi của Polkadot. Hơn nữa, 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 bất lợi của nó. Để đảm bảo bất kỳ ai cũng có thể xác minh giao dịch, 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ử 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

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 đánh đổi hiệu suất bằng sự tập trung, hay đánh đổi hiệu quả bằng lòng tin được thiết lập trước, mà thay vào đó, thông qua thiết kế giao thức linh hoạt, 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 bảo mật, phi tập trung và hiệu suất cao.

Trong việc theo đuổi việc ứ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 là giải pháp thực sự có thể hỗ trợ sự phát triển lâu dài của Web3.