Cân bằng giữa khả năng mở rộng, tính bảo mật và Phi tập trung: Quyết định công nghệ của Polkadot

Trong bối cảnh blockchain đang không ngừng tìm kiếm hiệu suất cao hơn, một vấn đề quan trọng dần hiện ra: Liệu có phải hy sinh tính bảo mật và tính đàn hồi của hệ thống trong khi mở rộng hiệu suất?

Đây không chỉ là thách thức về mặt 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 nền tảng hy sinh sự tin tưởng và an toàn thì thường khó có thể hỗ trợ đổi mới thực sự bền vững.

Polkadot với tư cách là một trong những động lực quan trọng cho khả năng mở rộng Web3, có phải đã hy sinh một số điều để đạt được mục tiêu có khả năng xử lý cao và độ trễ thấp? Mô hình rollup của nó có phải đã nhượng bộ về Phi tập trung, tính bảo mật hoặc khả năng tương tác mạng?

Bài viết này sẽ xoay quanh những vấn đề này, phân tích sâu sắc sự lựa chọn và đánh đổi trong thiết kế khả năng mở rộng của Polkadot, đồng thời 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 toàn và 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 độ 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 viên và chuỗi trung gian tập trung, liệu điều này có thể tạo ra rủi ro tập trung ở một số khía cạnh? Có khả năng hình thành điểm lỗ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 vận hành Rollup phụ thuộc vào bộ sắp xếp của chuỗi trung gian kết nối, và giao tiếp của nó sử dụng 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 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 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 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ể thực hiện mở rộng theo chiều 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 bởi tính năng "mở rộng linh hoạt". Trong quá trình thiết kế, phát hiện 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ó.

Do 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 minh. 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 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 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 trung gian 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 sẽ không có hành vi độc hại, từ đó đảm bảo tính hoạt độ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ì tính năng "không cần tin tưởng" và "không cần giấy phép" của hệ thống. Bất kỳ ai cũng nên có khả năng 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à: 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, do đó cần phải tuyên bố rõ ràng trong đầu ra rằng việc xác minh nên được thực hiện trên core Polkadot nào.

Thiết kế này đã đạt được sự đảm bảo 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 rollup trong quy trình khả dụng và đảm bảo tính chính xác của phân phối 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, một nhóm gồm khoảng 5 người xác thực sẽ 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ệ do bộ sắp xếp gửi, trong đó chứa các khối rollup và các 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 và sẽ được các người xác thực trên chuỗi trung gian thực thi 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ọ 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 rằng hệ thống luôn duy trì thuộc tính không cần tin tưởng và không cần giấy 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 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ề tính bảo mật. An toàn của rollup được bảo đảm 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.

Thông qua 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 giới hạn hoặc 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 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 đầ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 thông lượng cao hơn và độ trễ thấp hơn không thể tránh khỏi việc tạo ra 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 của RFC103 để phù hợp với các trường hợp 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 core cố định, hoặc điều chỉnh thủ công qua off-chain;

• 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 bằ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ể.

Tính 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 không ảnh hưởng đến thông lượng truyền tin.

Thông tin liên lạc 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 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 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ập nhật 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 đánh đổi nào?

Như mọi người đã biết, việc nâng cao hiệu suất thường đánh đổi bằng sự hy sinh về Phi tập trung và tính an toàn. Tuy nhiên, 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 mấy ấn tượng.

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 đó thực hiện khả năng mở rộng bằng kiến trúc một lớp 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 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 staked, càng nhiều phân phối. Ví dụ, nếu staked 1% của người xác thực sẽ nhận đượ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 bị 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 sự tập trung hóa của các nút xác thực. Các nút có nhiều staking 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 trầm trọ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, 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 trong 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 đoạn sẽ bị tiết 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ị 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 hoàn toàn nằm trong tầm kiểm soát của mình, hoặc thông qua cuộc tấn công DDoS để ngăn chặn các xác thực viên trung thực, từ đó làm sai lệch 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 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ộ quyền 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 tiền đặt cọc.

Avalanche

Avalanche áp 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 ~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. Nhưng Avalanche cho phép các validator tự do lựa chọn tham gia subnet, và subnet có thể thiết lập các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi sự Phi tập trung và an toàn.

Tại Polkadot, tất cả các rollup chia sẻ sự bảo vệ 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 Phi 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ó khăn trong việc 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à 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à Phi tập trung (có một số thậm chí chỉ có một sequencer), tồn tại các vấn đề như bảo mật 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 lượng dữ liệu có thể xử lý cho từng giao dịch. Nhu cầu tính toán để tạo ra bằng chứng không biết là rất cao, và cơ chế "người thắng tất cả" dễ dẫn đến Phi 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 trong mỗi lô, khi 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 gấp 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 gia tăng 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

Cái kết 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, đổi lòng tin đã được thiết lập lấy hiệu quả, 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 tìm kiếm ứ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ợ phát triển lâu dài cho Web3.