Cân bằng khả năng mở rộng của Blockchain: Lấy Polkadot làm ví dụ
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 dần hiện ra: làm thế nào để nâng cao hiệu suất mà không hy sinh 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à 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 sự tin tưởng và an toàn, thường khó có thể duy trì đổi mới thực sự bền vững.
Bài viết này sẽ đi sâu vào việc thảo luận về sự đánh đổi và cân nhắc trong thiết kế khả năng mở rộng của Polkadot, 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, phân tích những con đường khác nhau mà chúng chọn 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 tính linh hoạt và phân quyền
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). Việc chạy 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 cũng 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 qua một core của chuỗi trung gian, chỉ cần đáp ứng 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 hành.
Sự cân nhắc về 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 nhân 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). Trong quá trình thiết kế, phát hiện rằng vì việc xác thực khối rollup không cố định thực hiện trên một nhân 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 nộp khối cho chuỗi trung gian là không cần giấy phép, không cần tin tưởng, bất kỳ ai cũng có thể nộp khối lên bất kỳ core nào được phân bổ cho rollup để xác thực. Kẻ tấn công có thể lợi dụng điều này để lặp đi lặp lại việc nộp các khối hợp pháp đã được xác thực trước đó lên các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó giảm thiểu thông lượng và hiệu suất tổng thể 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 chính của hệ thống.
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": ví dụ 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 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ể có bất kỳ giả định nào về sự tin cậy đối với 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 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, vì vậy cần phải tuyên bố rõ ràng trong đầu ra rằng việc xác thực nên được thực hiện trên lõi Polkadot nào.
Thiết kế này đảm bảo cả tính linh hoạt và an toàn. 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ỳ 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 (candidate receipt) và chứng minh tính hợp lệ (PoV) do bộ sắp xếp gửi, trong đó chứa 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 thực thi lại bởi các người xác thực trên chuỗi tiếp nối.
Kết quả xác thực bao gồm một core selector, được sử 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ố này với core mà mình phụ trách; nếu không nhất quán, 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 các hành vi độc hại như thao túng vị trí xác minh của các 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 thỏa hiệp về mặt an ninh. 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ì sự sống.
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 minh tất cả các tính toán trên core mà không cần đặt bất kỳ 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 linh hoạt
Mở rộng linh hoạt sẽ không giới hạn tính khả thi lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện tính toán hoàn chỉnh Turing trong môi trường WebAssembly, miễn là việc thực hiện trong một lần không vượt quá 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 tăng cường, 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 chắc chắn sẽ dẫn đến độ 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 để 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.
Sự 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ể 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 trước 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 sẽ không ảnh hưởng đến thông lượng truyền tải thông điệp.
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 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 (off-chain messaging), 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.
Sự cân nhắc 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 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 như mong đợi.
Solana
Solana không sử dụng cấu trúc phân đoạn của Polkadot hoặc Ethereum, mà thay vào đó triển khai khả năng mở rộng bằng 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 người lãnh đạo, với TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lên lịch lãnh đạo 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 staking, càng nhiều phân bổ. Ví dụ, một người xác thực 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 đượ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ừ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 của các nút xác thực. Các nút có nhiều tài sản thế chấp 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 rủi ro hệ thống bị tê liệt sau khi bị tấn công.
Solana hy sinh khả năng 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 trên mạng thử nghiệm riêng, 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ơ về an ninh: danh tính của các nút xác thực phân mảnh sẽ bị lộ trước. Bản white paper 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 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 mảnh nào đó bị kiểm soát hoàn toàn, hoặc ngăn chặn các xác thực viên trung thực thông qua cuộc tấn công DDoS, từ đó sửa đổi trạng thái.
So với, những 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 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à khiến kẻ tấn công mất tài sản.
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 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 người xác thực tự do chọn tham gia subnet, và subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi sự phi tập trung và an ninh.
Tại Polkadot, tất cả các rollup đều chia sẻ bảo mật 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 toàn, 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 lớp phía trên của ngăn xếp.
Optimistic Rollup
Hiện nay 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 vấn đề về độ an toàn không đủ, cách biệt nhau, độ trễ cao (cần chờ đợi thời gian chứng minh gian lận, thường mất 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 đơn lẻ. 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 chiến thắng nhận 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 khối lượng giao dịch mỗi lô, khi có 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 đủ Turing hoàn chỉnh 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ử dụng dữ liệu của ZK rollup cũng sẽ làm tăng thêm 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 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à lệ phí cho 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 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 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 việc theo đuổi ứng dụng quy mô lớn hơn ngày nay, "mở rộng không cần tin tưởng" mà Polkadot kiên trì có thể là giải pháp thực sự hỗ trợ sự phát triển bền vững của Web3.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
9 thích
Phần thưởng
9
6
Chia sẻ
Bình luận
0/400
GateUser-a5fa8bd0
· 1giờ trước
Học tốt dot! Ngành cũ không còn đáng tin cậy nữa.
Xem bản gốcTrả lời0
AirdropworkerZhang
· 08-01 00:33
Hiệu suất cao quá, chi phí thấp quá, ông chủ tôi đi khai thác rồi.
Xem bản gốcTrả lời0
MEVHunter
· 07-31 10:51
meh... relaychain của dot vẫn bị tắc nghẽn dưới áp lực mempool nặng nề, thật sự. đã thấy những đợt lưu lượng độc hại tăng vọt tuần trước.
Xem bản gốcTrả lời0
Lonely_Validator
· 07-31 10:51
Người chơi lâu năm của blockchain công cộng, Dot luôn được ưa chuộng.
Mở rộng linh hoạt của Polkadot: Cân bằng hiệu suất và an ninh Web3 không thỏa hiệp
Cân bằng khả năng mở rộng của Blockchain: Lấy Polkadot làm ví dụ
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 dần hiện ra: làm thế nào để nâng cao hiệu suất mà không hy sinh 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à 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 sự tin tưởng và an toàn, thường khó có thể duy trì đổi mới thực sự bền vững.
Bài viết này sẽ đi sâu vào việc thảo luận về sự đánh đổi và cân nhắc trong thiết kế khả năng mở rộng của Polkadot, 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, phân tích những con đường khác nhau mà chúng chọn 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 tính linh hoạt và phân quyền
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). Việc chạy 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 cũng 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 qua một core của chuỗi trung gian, chỉ cần đáp ứng 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 hành.
Sự cân nhắc về 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 nhân 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). Trong quá trình thiết kế, phát hiện rằng vì việc xác thực khối rollup không cố định thực hiện trên một nhân 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 nộp khối cho chuỗi trung gian là không cần giấy phép, không cần tin tưởng, bất kỳ ai cũng có thể nộp khối lên bất kỳ core nào được phân bổ cho rollup để xác thực. Kẻ tấn công có thể lợi dụng điều này để lặp đi lặp lại việc nộp các khối hợp pháp đã được xác thực trước đó lên các core khác nhau, tiêu tốn tài nguyên một cách ác ý, từ đó giảm thiểu thông lượng và hiệu suất tổng thể 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 chính của hệ thống.
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": ví dụ 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 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ể có bất kỳ giả định nào về sự tin cậy đối với 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 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, vì vậy cần phải tuyên bố rõ ràng trong đầu ra rằng việc xác thực nên được thực hiện trên lõi Polkadot nào.
Thiết kế này đảm bảo cả tính linh hoạt và an toàn. 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ỳ 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 (candidate receipt) và chứng minh tính hợp lệ (PoV) do bộ sắp xếp gửi, trong đó chứa 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 thực thi lại bởi các người xác thực trên chuỗi tiếp nối.
Kết quả xác thực bao gồm một core selector, được sử 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ố này với core mà mình phụ trách; nếu không nhất quán, 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 các hành vi độc hại như thao túng vị trí xác minh của các 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 thỏa hiệp về mặt an ninh. 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ì sự sống.
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 minh tất cả các tính toán trên core mà không cần đặt bất kỳ 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 linh hoạt
Mở rộng linh hoạt sẽ không giới hạn tính khả thi lập trình của rollup. Mô hình rollup của Polkadot hỗ trợ thực hiện tính toán hoàn chỉnh Turing trong môi trường WebAssembly, miễn là việc thực hiện trong một lần không vượt quá 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 tăng cường, 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 chắc chắn sẽ dẫn đến độ 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 để 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.
Sự 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ể phụ thuộc vào các biến trên chuỗi hoặc ngoài chuỗi. Ví dụ:
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 sẽ không ảnh hưởng đến thông lượng truyền tải thông điệp.
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 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 (off-chain messaging), 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.
Sự cân nhắc 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 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 như mong đợi.
Solana
Solana không sử dụng cấu trúc phân đoạn của Polkadot hoặc Ethereum, mà thay vào đó triển khai khả năng mở rộng bằng 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 người lãnh đạo, với TPS lý thuyết có thể đạt 65,000.
Một thiết kế quan trọng là cơ chế lên lịch lãnh đạo công khai và có thể xác minh trước.
PoH và 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 thực. Các nút có nhiều tài sản thế chấp 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 rủi ro hệ thống bị tê liệt sau khi bị tấn công.
Solana hy sinh khả năng 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 trên mạng thử nghiệm riêng, 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ơ về an ninh: danh tính của các nút xác thực phân mảnh sẽ bị lộ trước. Bản white paper 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 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 mảnh nào đó bị kiểm soát hoàn toàn, hoặc ngăn chặn các xác thực viên trung thực thông qua cuộc tấn công DDoS, từ đó sửa đổi trạng thái.
So với, những 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 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à khiến kẻ tấn công mất tài sản.
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 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 người xác thực tự do chọn tham gia subnet, và subnet có thể đặt ra các yêu cầu bổ sung về địa lý, KYC, v.v., đánh đổi sự phi tập trung và an ninh.
Tại Polkadot, tất cả các rollup đều chia sẻ bảo mật 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 toàn, 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 lớp phía trên của ngăn xếp.
Optimistic Rollup
Hiện nay 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 vấn đề về độ an toàn không đủ, cách biệt nhau, độ trễ cao (cần chờ đợi thời gian chứng minh gian lận, thường mất 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 đơn lẻ. 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 chiến thắng nhận 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 khối lượng giao dịch mỗi lô, khi có 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 đủ Turing hoàn chỉnh 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ử dụng dữ liệu của ZK rollup cũng sẽ làm tăng thêm 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 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à lệ phí cho 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 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 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 việc theo đuổi ứng dụng quy mô lớn hơn ngày nay, "mở rộng không cần tin tưởng" mà Polkadot kiên trì có thể là giải pháp thực sự hỗ trợ sự phát triển bền vững của Web3.