Cân nhắc về khả năng mở rộng Web3: Giải pháp của Polkadot

Trong bối cảnh blockchain ngày càng hướng tới hiệu suất cao hơn, một vấn đề then chốt dần dần hiện ra: Làm thế nào để vừa mở rộng hiệu suất vừa đảm bảo 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à 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 lòng tin và an ninh, thường khó có thể duy trì đổi mới thực sự bền vững.

Polkadot với tư cách là một động lực quan trọng cho khả năng mở rộng Web3, mô hình rollup của nó có đang nhượng bộ về phân cấp, an ninh hay khả năng tương tá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à đánh đổi 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 những 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à phân cấp.

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 tiếp nối, điều này có thể tạo ra rủi ro tập trung ở một số khía cạnh không? Liệu có khả năng hình thành điểm lỗi đơn hoặc kiểm soát, từ đó ảnh hưởng đến đặc tính phi tập trung của nó không?

Việc vận hành Rollup phụ thuộc vào một bộ sắp xếp của chuỗi trung gian, và 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 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. 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 đáp ứng một điều kiện: phải là chuyển 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 mở rộng theo chiều dọc

Rollup có thể đạt được sự 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 tính năng "mở rộng linh hoạt". Trong quá trình thiết kế, chúng tôi phát hiện ra rằng việc xác minh 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ó.

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 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 lặp 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ừ đó làm giảm tổng throughput 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 tính 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 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 có hành vi độc hại, do đó đảm bảo tính sống động 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ì phải 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 đổi trạng thái của 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 thông tin đồng thuận duy nhất đáng tin cậy, vì vậy phải rõ ràng tuyên bố trong đầu ra rằng nên thực hiện xác minh trên core 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 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 khoảng 5 người xác thực sẽ trước tiên xác minh tính hợp lệ của nó. Họ nhận các biên lai ứng cử và chứng minh tính hợp lệ do trình sắp xếp gửi, bao gồm khối rollup và chứng minh lưu trữ tương ứng. Thông tin này sẽ được chuyển cho các hàm xác thực của chuỗi song song xử lý, và sẽ được 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 minh bao gồm một bộ chọn core, được sử dụng để xác định core nào sẽ xác minh khối. Người xác minh sẽ so sánh chỉ số đó với core mà họ chịu trách nhiệm; 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 duy trì các thuộc tính không cần tin cậy và không cần cấp 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 thực, đả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ề 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 là có thể 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 nó hoàn toàn đế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 hoặc 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ế 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, 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.

Sự phức tạp

Thông lượng cao hơn và độ trễ thấp hơn chắc chắn sẽ dẫn đến 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 linh hoạt tài nguyên 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, 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 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 trước bằng cách sử dụng 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 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ổ của nó.

Trong tương lai, Polkadot cũng sẽ hỗ trợ truyền tin ngoài chuỗi, với chuỗi trung gian làm 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ừ đó 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 thỏa hiệp nào?

Như mọi người đều biết, việc nâng cao hiệu suất thường phải hy sinh tính phi tập trung và độ an toàn. Nhưng từ góc độ hệ số Nakamoto, ngay cả khi một số đối thủ cạnh tranh của Polkadot có mức độ phi tập trung thấp, hiệu suất của chúng cũng không như mong đợi.

Một chuỗi công khai A

Một chuỗi công khai A không sử dụng kiến trúc phân đoạn của Polkadot hoặc Ethereum, mà thay vào đó thực hiện khả năng mở rộng bằng kiến trúc một lớp với khả năng thông lượng cao, dựa vào chứng minh lịch sử, 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 trước và có thể xác minh:

• 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 staking, càng nhiều phân bổ. Ví dụ, một validator staking 1% sẽ có khoảng 1% cơ hội tạo khối;

• Tất cả những người tạo khối đều được công bố trước, điều này 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ừng hoạt động.

Lịch sử chứng minh rằng việc xử lý song song yêu cầu phần cứng rất cao, dẫn đến sự tập trung của các nút xác minh. 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 trầm trọng thêm sự tập trung và cũng tăng nguy cơ hệ thống ngừng hoạt động sau khi bị tấn công.

Một blockchain công cộng A để đạt được TPS, đã hy sinh sự phi tập trung và khả năng chống tấn công, hệ số Nakamoto của nó chỉ là 20, thấp hơn nhiều so với Polkadot là 172.

Một chuỗi công khai B

Một chuỗi công khai B tuyên bố TPS có thể đạt 104,715, nhưng con số này được đạt được 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 tới 128K TPS trên mạng công khai phi tập trung.

Một cơ chế đồng thuận của chuỗi công khai B tồn tại nguy cơ an ninh: Danh tính của các nút xác thực phân đoạn có thể bị lộ trước. Tài liệu trắng của chuỗi công khai B 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ế "vỡ nợ của con bạc", kẻ tấn công có thể chờ đợi một phân đoạn mà họ hoàn toàn kiểm soát, hoặc thông qua cuộc tấn công DDoS để chặn các xác thực viên trung thực, từ đó làm thay đổi trạng thái.

So với đó, các 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 được danh tính của các xác thực, việc tấn công cần phải đặt cược toàn bộ kiểm soát để thành công, chỉ cần có một 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.

Một chuỗi công cộng C

Một chuỗi công khai C sử dụng kiến trúc mạng chính + mạng con để 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 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ưởng của Polkadot: giảm tải cho từng shard để đạt được khả năng mở rộng. Tuy nhiên, một blockchain công cộng nào đó cho phép các validator tự do lựa chọn tham gia vào subnet, và subnet có thể đặt ra các yêu cầu bổ sung như địa lý, KYC, v.v., hy sinh tính phi tập trung và an toàn.

Trên Polkadot, tất cả các rollup đều chia sẻ một bảo đảm an ninh thống nhất; trong khi đó, các subnet của một blockchain công cộng C 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 tính an ninh, vẫn cần thỏa hiệp về hiệu suất và khó có thể cung cấp cam kết an ninh định lượng.

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 tầng rollup, thay vì giải quyết vấn đề trực tiếp ở tầng 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 (một số thậm chí chỉ có một sequencer), tồn tại vấn đề về an ninh không đủ, cô lập lẫn 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 bằng chứng không kiến thức 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 số lượng giao dịch mỗi lô, và trong thời điểm nhu cầu cao có thể gây ra tắc nghẽn mạng, tăng gas, ả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 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ả năng sẵn có dữ liệu của ZK rollup cũng sẽ làm trầm trọng thêm nhược điểm 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ẵn có dữ liệu bổ sung, làm tăng thêm chi phí và phí người dùng.

Kết luận

Đỉnh điểm 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 cách tập trung hóa, hay đánh đổi hiệu quả bằng cách thiết lập lòng tin trước, mà thay vào đó, thông qua khả năng 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, đã đạ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 mà việc theo đuổi ứng dụng quy mô lớn đang trở nên quan trọng hơn, "mở rộng không tin cậy" mà Polkadot kiên định có thể là giải pháp thực sự hỗ trợ cho sự phát triển lâu dài của Web3.