Con đường đổi mới của Polkadot: Làm thế nào để đạt được sự cân bằng giữa khả năng mở rộng, tính bảo mật và Phi tập trung

Lựa chọn về khả năng mở rộng Blockchain: Con đường đổi mới của Polkadot

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 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à độ 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 trên nền tảng hy sinh niềm 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 quan trọng cho khả năng mở rộng Web3, Polkadot có phải đã thực hiện một số thỏa hiệp trong việc theo đuổi mục tiêu thông lượng cao và độ trễ thấp? Mô hình rollup của nó có phải đã nhượng bộ về phi tập trung, an ninh hoặc 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, 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 trong ba yếu tố: hiệu suất, an ninh 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à 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 (Relay Chain), điều này có thể tạo ra rủi ro trung tâm ở một số khía cạnh không? 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ó không?

Việc hoạt động của 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 yêu cầu 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 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 qua một core nào đó của chuỗi trung gian, chỉ cần đáp ứng một điều kiện tiên quyết: phải là một 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.

Thỏa hiệp mở rộng dọc

Rollup có thể đạt được khả năng 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 "弹性扩展"(Elastic Scaling). Trong quá trình thiết kế, đã phát hiện ra rằng, do việc xác thực khối rollup không bị 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 tới 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 tới bất kỳ core nào được phân bổ cho rollup để xác minh. Kẻ tấn công có thể tận 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 đó tới 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à 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 điểm chính của hệ thống.

Vấn đề niềm tin của Sequencer

Một giải pháp đơn giản là thiết lập giao thức "có giấy phép": ví dụ, á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, 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 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 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 lựa 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 thông tin đồng thuận duy nhất đáng tin cậy, vì vậy 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 đạ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 quá trình 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ẽ kiểm tra tính hợp pháp của nó. Họ nhận được biên lai ứng cử viên (candidate receipt) và chứng minh hiệu lực (PoV), trong đó chứa 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 chuỗi song song, đượ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 thực bao gồm một core selector, dùng để chỉ định nên xác thực khối trên core nào. Người xác thực sẽ đối chiếu chỉ số này với core mà họ chịu trách nhiệm; nếu không一致, khối đó sẽ bị loại bỏ.

Cơ chế này đảm bảo rằng 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 phép, tránh việc các tác nhân độc hại như bộ định vị thao túng vị trí xác thực, đảm bảo rằng 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ề mặt 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à đủ để duy trì sự sống.

Nhờ vào giao thức ELVES, Polkadot đã mở rộng hoàn toàn tính bảo mật của mình đến tất cả các rollup, xác thực tất cả các phép tính trên core, mà không cần phải hạn chế hoặc giả định 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 tính an toàn.

Tính tổng 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 hoàn chỉnh Turing 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.

Độ phức tạp

Khối lượng thông qua cao hơn và độ trễ thấp hơn không thể tránh khỏi sẽ mang lại sự phức tạp, đây là cách cân bằng 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 linh động 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, để thích ứng 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 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 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ể.

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 mở rộng linh hoạt sẽ không ảnh hưởng đến thông lượng truyền tải tin nhắn.

Giao tiếp tin nhắn 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, 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 trung gian đóng vai trò là mặt điều khiển, thay vì mặt dữ liệu. Bản nâng cấp này sẽ cải thiện 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 thỏa hiệp của các giao thức khác

Như mọi người đã biết, việc cải thiện hiệu suất thường phải đánh đổi giữa sự phi tập trung và tính an toàn. Nhưng 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 kiến trúc phân đoạn của Polkadot hay Ethereum, mà thực hiện khả năng mở rộng bằng cách sử dụ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ế phân bổ 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 khối lượng staking;
  • Càng nhiều cổ phần, càng nhiều phân phối. Ví dụ, một người xác thực có cổ phần 1% sẽ nhận đượ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 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 việc tập trung hóa các nút xác thực. Nút có nhiều điểm đặt hơn thì cơ hội tạo khối càng lớn, nút nhỏ gần như không có slot, càng làm gia tăng sự tập trung hóa và cũng tăng rủi ro hệ thống bị sập sau khi bị tấn công.

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

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ó những rủi ro 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. Sách trắng của TON cũng chỉ rõ, 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ị khai thác một cách ác ý. Do thiếu cơ chế "người chơi phá sản", kẻ tấn công có thể chờ một phân mảnh bị kiểm soát hoàn toàn bởi họ, hoặc ngăn chặn các xác thực viên trung thực bằng cách tấn công DDoS, từ đó sửa đổ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ộ chậm, kẻ tấn công không thể biết trước danh tính của các xác thực, cuộc tấn công cần phải cược tất cả để 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 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 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 khối để đạt được khả năng 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ể thiết lập 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 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 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 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 phía 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. Một số thậm chí chỉ có một sequencer, dẫn đến việc thiếu an toàn, bị cô lập lẫn nhau, độ trễ cao cần phải chờ thời gian chứng minh gian lận, thường 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 mà một giao dịch có thể xử lý. Nhu cầu tính toán để tạo ra bằng chứng không biết (zero-knowledge proof) rất cao, và cơ chế "người thắng cuộc sẽ lấy hết" dễ dẫn đến sự tập trung hó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ô, dẫn đến tắc nghẽn mạng và tăng giá gas trong thời gian có nhu cầu cao, ả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 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 truy cập 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 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 truy cập dữ liệu bổ sung, làm tăng chi phí và phí 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 trao đổi tính năng hiệu suất để đổi lấy sự tập trung hóa, hay trao đổi hiệu quả để đổi lấy sự tin cậy đã được thiết lập, mà thay vào đó, thông qua thiết kế giao thức linh hoạt mở rộng, 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 việc ứng dụng quy mô lớn hơn ngày nay, "khả năng 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ợ sự phát triển lâu dài của Web3.

Xem bản gốc
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Phần thưởng
  • 5
  • Chia sẻ
Bình luận
0/400
DefiOldTrickstervip
· 07-12 09:17
Cái già mới hiểu, đường vẫn là Solana thơm... Lợi suất ba năm hai nghìn lần không phải đùa.
Xem bản gốcTrả lời0
DevChivevip
· 07-12 09:15
Trong Web3, một đồ ngốc đang phấn đấu.
Xem bản gốcTrả lời0
rugged_againvip
· 07-12 09:12
Không ai nói rằng Dot đã chết từ lâu.
Xem bản gốcTrả lời0
BlindBoxVictimvip
· 07-12 08:58
Có thể đừng làm rối rắm như vậy không? An toàn mới là quan trọng nhất.
Xem bản gốcTrả lời0
CommunityLurkervip
· 07-12 08:52
Đáng tin cậy, Polkadot thật sự rất tuyệt
Xem bản gốcTrả lời0
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)