Sự cân bằng của khả năng mở rộng Blockchain: Cân bằng giữa Polkadot và 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 lên: liệu có nhất thiết phải hy sinh tính bảo mật và tính linh hoạt của hệ thống trong khi mở rộng hiệu suất? Đâ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 nền tảng hy sinh sự tin cậy và tính bảo mật thì thường khó có thể hỗ trợ cho đổi mới thực sự bền vững.

Polkadot, với vai trò là một trong những người thúc đẩy quan trọng cho khả năng mở rộng Web3, liệu mô hình rollup của nó có phải đã hy sinh cho tính phi tập trung, an ninh hay khả năng tương tác mạng? Bài viết này sẽ đi sâu vào phân tích những sự hy sinh 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, khám phá những lựa chọn khác nhau của chúng 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 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 tiếp hợp (Relay Chain), đ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? Có thể 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ó không?

Chạy Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian ( sequencer ), 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 cậy, bất kỳ ai có kết nối mạng đều có thể sử dụng nó, kết nố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 đó trong 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 lên.

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

Rollup có thể đạt được việc 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 "弹性扩展"(Elastic Scaling). Trong quá trình thiết kế, chúng tôi nhận thấy rằng việc xác thực khối rollup không được cố định trên một lõi nào có thể ảnh hưởng đến tính linh hoạt của nó.

Bởi vì giao thức gửi khối đến 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 đế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 đi gửi lại 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 ý, 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ự sử dụng hiệu quả tài nguyên của chuỗi tiếp theo 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 theo cách "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 rằng trình sắp xếp sẽ không có hành vi độc hại, từ đó đảm bảo tính khả dụng của rollup.

Tuy nhiên, trong triết lý thiết kế của Polkadot, chúng ta không thể có bất kỳ giả định tin cậy 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 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 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, vì vậy cần phải rõ ràng trong đầu ra về việc nên thực hiện xác minh trên Polkadot core nào.

Thiết kế này đảm bảo sự linh hoạt và an toàn đồng thời. Polkadot sẽ thực hiện lại các 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 của Polkadot (DA), 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 (candidate receipt) và chứng minh tính hợp lệ (PoV) được gửi bởi bộ sắp xếp, trong đó bao gồm 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, do các xác thực trên chuỗi tiếp nối thực hiện lại.

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ỉ mục này với core mà họ 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 giữ được các thuộc tính không cần tin tưởng và không cần cấp phép, ngăn chặn các hành vi xấu của những kẻ thao túng vị trí xác thực như 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 đàn hồi.

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ề độ 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ì tính sống sót.

Nhờ vào giao thức ELVES, Polkadot mở rộng tính bảo mật của nó một cách toàn diệ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 đặt bất kỳ giới hạn hay giả định nào về số lượng core 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 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, 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 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ẽ 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 độ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 kịch bản 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, các 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 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.

Thông tin liên lạc qua rollup được thực hiện bởi lớp truyền tải dưới cùng, không gian khối liên lạc 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 thông ngoài chuỗi (off-chain messaging), với chuỗi tiếp nối đóng vai trò là mặt điều khiển, 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 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 đã đưa ra những sự đánh đổi nào?

Như mọi người đều biết, việc nâng cao hiệu suất thường đi kèm với việc hy sinh sự 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ủ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 tính mở rộng thông qua kiến trúc lớp đơn với 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, TPS lý thuyết 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 số lượng stake;

• Càng nhiều staking, càng nhiều phân phối. Ví dụ, một validator staking 1% sẽ nhận được khoảng 1% cơ hội tạo khối;

• Tất cả các người tạo khối được công bố trước, làm tăng rủi ro mạng bị tấn công DDoS có hướng và thường xuyên bị sập.

PoH và xử lý song song yêu cầu phần cứng cực cao, dẫn đến sự tập trung hóa của các nút xác nhận. Các nút có nhiều cổ phần 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, làm gia tăng thêm sự 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 tính phi tập trung và khả năng chống tấn công để theo đuổi TPS, với hệ số Nakamoto 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 đoạn sẽ bị lộ trước. Sách trắng của TON cũng chỉ ra rằng đ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ờ một phân đoạn bị kiểm soát hoàn toàn, hoặc thông qua tấn công DDoS để chặn các xác thực viên trung thực, từ đó thay đổ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à 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 đặ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 đ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 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 phụ).

Mỗi subnet lý thuyết TPS có thể đạt ~5,000, tương tự như cách tiếp cận của Polkadot: giảm tải cho từng shard để đạt được sự mở rộng. Tuy nhiên, Avalanche cho phép các validator tự do chọn tham gia vào subnet, và subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., 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 đồ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 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 nay hầu hết các Optimistic rollup đều là tập trung hóa ( có một số thậm chí chỉ có một sequencer ), tồn tại vấn đề về an toàn, 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ị 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 bằng chứng không biết rất cao, và cơ chế "người thắng tất cả" 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 khoảng 2x10^6 lần chi phí của giao thức an ninh kinh tế cốt lõi 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 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 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

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 cộng khác, Polkadot không đi theo con đường đánh đổi hiệu suất bằng cách tập trung hóa, hay đánh đổi hiệu quả bằng cách tạo ra niềm tin trước, 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 toàn, phi tập trung và hiệu suất cao.

Trong bối cảnh hiện nay, khi mà việc ứng dụng quy mô lớn đang được theo đuổi, "mở rộng không tin cậy" mà Polkadot kiên định có lẽ mới là giải pháp thực sự hỗ trợ sự phát triển lâu dài của Web3.