Thỏa hiệp về khả năng mở rộng: Lựa chọn giữa Polkadot và Web3

Trong bối cảnh 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 để đảm bảo an toàn và tính linh hoạt của hệ thống đồng thời mở rộng hiệu suất? Đâ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 dựa trên việc hy sinh lòng tin và 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 chính cho khả năng mở rộng Web3, Polkadot có liệu đã phải đưa ra một số thỏa hiệp trong việc theo đuổi mục tiêu có 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 hay 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ự 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, khám phá 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.

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ể mang lại 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ác đặc tính phi tập trung của nó không?

Việc vận hành Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian, 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 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 triển.

Sự đánh đổi của mở rộng theo chiều dọc

Rollup có thể đạt được khả năng 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 thông qua tính năng "mở rộng linh hoạt". Trong quá trình thiết kế, chúng tôi nhận thấy rằng, do việc xác minh 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 cấp 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 nhận. Kẻ tấn công có thể lợi dụng điều này, gửi đi gửi lại những khối hợp pháp đã được xác nhận 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 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 tiếp relais 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 vào bộ sắp xếp không có hành vi độc hại, từ đó đảm bảo tính khả thi 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ì cần duy trì các đặc tính "không cần tin cậy" và "không cần sự cho 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 đổi 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 đáng tin cậy duy nhất cho tất cả thông tin đồng thuận, vì vậy phải tuyên bố rõ ràng trong đầu ra rằng xác thực nên được thực hiện trên core Polkadot 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 bất kỳ dữ liệu nào từ rollup đượ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 xác thực viên sẽ xác minh tính hợp pháp của nó. Họ nhận các biên lai ứng cử và chứng minh tính hợp lệ do bộ sắp xếp gửi, trong đó chứa các khối rollup và chứng minh lưu trữ tương ứng. Thông tin này sẽ được xử lý bởi chức năng xác thực của chuỗi song song, và sẽ được thực thi 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 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 đó 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 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 cấp phép, tránh sự thao túng vị trí xác thực của các tác nhân độc hại như bộ định dạng, đả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 đã thỏa hiệp về tính bảo mật. 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 sót.

Nhờ vào 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 thực tất cả các phép toán trên core mà không cần đặt ra 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 khả năng mở rộng thực sự mà không hy sinh sự an toàn.

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à việc thực hiện trong một lần được 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

Sự thông lượng cao hơn và độ trễ thấp hơn không thể tránh khỏi sẽ đư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, nhằm 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.

Độ 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 bằng tay ngoài chuỗ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 đáng kể.

khả năng tương tác

Polkadot hỗ trợ tính 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 lưu lượng truyền tin.

Giao tiếp tin nhắn xuyên 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 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 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. 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ừ đó 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 đã có những thỏa hiệp nào?

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à tính bảo mật. Tuy nhiên, từ góc độ chỉ 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 họ cũng không 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 đó sử dụng kiến trúc một lớp với khả năng thông lượng 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 bằng CPU và cơ chế đồng thuận dựa trên người lãnh đạo, lý thuyết TPS có thể đạt tới 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 phối. Ví dụ, một người xác nhận đặ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 rủi ro mạng bị tấn công DDoS có định hướng và thường xuyên bị ngắt quãng.

PoH và xử lý song song đòi hỏi phần cứng rất cao, dẫn đến sự tập trung của các nút xác thực. Nút càng có nhiều điểm ký quỹ thì cơ hội tạo khối càng lớn, nút nhỏ hầu như không có slot, càng làm gia tăng sự tập trung, đồng thời 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, hệ số Nakamoto của nó chỉ là 20, thấp hơn nhiều so với Polkadot với 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ó lỗ hổng 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, 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ạm dụng. 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 được kiểm soát hoàn toàn, hoặc sử dụng tấn công DDoS để ngăn chặn các xác thực viên trung thực, từ đó can thiệp vào trạng thái.

So với, các validator 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 validator, 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 validator 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à quản lý người xác thực cùng mạng con P-Chain(.

Mỗi subnet lý thuyết TPS có thể đạt ~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 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 về địa lý, KYC, v.v., đánh đổi giữa phi tập trung và an toàn.

Trên 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. Nếu muốn tăng cường 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 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, tồn tại vấn đề an ninh không đủ, cách biệt với 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 ( và các vấn đề khác.

)# 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 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ệ thống. Để đảm bảo TPS, ZK rollup thường giới hạn số lượng giao dịch trên 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 cao điểm, ả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 gấp 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 nhược điểm của nó. Để đảm bảo bất kỳ ai cũng có thể xác minh giao dịch, vẫn 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ả 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

Đỉ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 khác, Polkadot không chọn con đường tập trung hóa để đổi lấy hiệu suất, cũng như không đánh đổi hiệu quả bằng cách thiết lập niềm tin trước, mà thay vào đó, nó đạ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 thông qua việc mở rộng linh hoạt, thiết kế giao thức không cần giấy 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.

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