Khả năng mở rộng và sự cân bằng: Polkadot tìm kiếm sự cân bằng trong hệ sinh thái Web3
Trong bối cảnh blockchain ngày càng tìm kiếm 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 để mở rộng hiệu suất mà không hy sinh tính bảo mật và tính đàn hồi 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à tính bảo mật, thường khó có thể hỗ trợ đổi mới thực sự bền vững.
Polkadot, như một động lực quan trọng cho khả năng mở rộng Web3, có phải đã hy sinh một số điều dưới 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ề tính phi tập trung, an ninh hay khả năng tương tác mạng? Bài viết này sẽ tập trung vào những vấn đề này, phân tích sâu sắc những lựa chọn và đánh đổi của Polkadot trong thiết kế khả năng mở rộng, đồng thời so sánh với các giải pháp của các chuỗi công khai khác, khám phá những lộ trình 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 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ể gây ra rủi ro tập trung trong một số khía cạnh? 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ác đặ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, giao tiếp 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 minh 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 hành.
Sự cân nhắc về mở rộng theo chiều 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 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 thực block rollup không được 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 tới 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 thực. Kẻ tấn công có thể lợi dụng điều này, gửi lại nhiều lần các khối hợp pháp đã được xác thực trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách độc hại, từ đó giảm tổng khả năng xử lý 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.
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ụ, áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng rằng các trình xếp hạng sẽ không có hành vi độc hại, từ đó đảm bảo tính khả dụng của rollup.
Tuy nhiên, trong thiết kế của Polkadot, chúng ta không thể đặt 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 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 thông tin đồng thuận duy nhất đáng tin cậy, do đó phải tuyên bố rõ ràng trong đầu ra nên thực hiện xác minh 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 việc phân bổ core thông qua giao thức kinh tế mã hóa ELVES.
Trước khi ghi dữ liệu vào lớp khả dụng của Polkadot (DA) trong bất kỳ khối rollup nào, 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ác biên lai ứng cử viên và bằng chứng hợp lệ do bộ sắp xếp gửi, bao gồm khối rollup và bằng chứng lưu trữ tương ứ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 xác thực trên chuỗi tiếp theo 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 để chỉ định nên xác minh khối trên core nào. Người xác minh sẽ so sánh chỉ số này với core mà họ 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 hành vi xấu từ các tác nhân như bộ điều chỉnh thao túng vị trí xác thực, đảm bảo ngay cả khi rollup sử dụng nhiều core cũng vẫn giữ được tính đàn hồi.
An toàn
Trong quá trình theo đuổi khả năng mở rộng, Polkadot không có bất kỳ sự thỏa hiệp nào về mặt an ninh. Sự an toàn của rollup được đảm bảo bởi chuỗi trung gian, chỉ cần một nhà sắp xếp trung thực là có thể duy trì sự sống.
Với 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 thực mọi phép toán trên core mà không cần 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 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 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à 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 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
Thông lượng cao hơn và độ trễ thấp hơn không thể tránh khỏi sẽ dẫn đến sự phức tạp, đây là cách duy nhất để 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 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 các yêu cầu RFC103 để phù hợp với các trường hợp 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ể 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 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 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 tin.
Giao tiếp tin nhắn 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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi tiếp nối là 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ăng cường hơn nữa khả năng mở rộng theo chiều dọc của hệ thống.
Các giao thức khác đã thực hiện những sự đánh đổi nào?
Như mọi người đã biết, việc nâng cao hiệu suất thường phải hy sinh sự 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 hơn, hiệu suất của chúng cũng không được 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à thực hiện khả năng mở rộng bằng kiến trúc một lớp với hiệu suất cao, dựa vào bằng chứng lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, với TPS lý thuyết có thể đạt tới 65,000.
Một thiết kế chính là cơ chế lập 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 số 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ó 1% cổ phần 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 bị sập.
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 chứng khoá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, càng làm trầm trọng thêm 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 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
Một dự án blockchain 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 cộng phi tập trung.
Cơ chế đồng thuận của dự án này 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ị lộ trước. Bản trắng giấy của nó 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ế "xổ số phá sản", kẻ tấn công có thể chờ đợi một phân đoạn nào đó hoàn toàn nằm trong sự kiểm soát của mình, hoặc thông qua tấn công DDoS để 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 trước, 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ộ để 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à khiến 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 X-Chain (chuyển khoả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 xác nhận viên tự do chọn tham gia subnet, và subnet có thể thiết lập các yêu cầu thêm về địa lý, KYC, v.v., hy sinh sự phi tập trung và an toàn.
Tại Polkadot, tất cả các rollup 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 toàn mặc định, một số thậm chí có thể hoàn toàn trung tâm hóa. 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 toàn có tính xác định.
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ề cơ bản không giải quyết được vấn đề, mà chỉ chuyển vấn đề lên tầng cao hơ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), gặp phải các vấn đề như thiếu an toàn, 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ị hạn chế 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 chứng minh không tri thức là 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 khối lượng giao dịch mỗi lô, và trong thời gian 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 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ử dụng 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 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à 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 blockchain công khai khác, Polkadot không chọn 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 niềm 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 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 ngày nay đang theo đuổi việc áp dụng quy mô lớn hơn, "mở rộng không cần 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 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.
13 thích
Phần thưởng
13
8
Chia sẻ
Bình luận
0/400
MysteryBoxOpener
· 07-22 22:03
dot thực sự vượt trội hơn các chuỗi công khai khác
Xem bản gốcTrả lời0
NotFinancialAdviser
· 07-22 21:00
Đừng thổi phồng nữa, dot cũng chỉ vậy thôi.
Xem bản gốcTrả lời0
LuckyBearDrawer
· 07-22 00:01
Đợt này DOT phải To da moon啊
Xem bản gốcTrả lời0
P2ENotWorking
· 07-19 22:40
Tốc độ nhanh có ích gì, trước tiên hãy sống sót đã rồi nói sau.
Xem bản gốcTrả lời0
BrokenDAO
· 07-19 22:39
Lại đang mô tả sự cân bằng hoàn hảo... Chúng ta còn nhớ đợt suy thoái sinh thái năm 2021 không?
Xem bản gốcTrả lời0
ser_we_are_early
· 07-19 22:39
Đỉnh! Tôi chỉ quan tâm đến một điều trong bài viết công nghệ này, tăng lên hay không tăng lên.
Xem bản gốcTrả lời0
DevChive
· 07-19 22:32
dot là tương lai, còn ai phản đối?
Xem bản gốcTrả lời0
MagicBean
· 07-19 22:31
polka chọn lựa kết quả, không thể không nói vẫn chắc chắn có thể To da moon
Cách tiếp cận của Polkadot: Khả năng mở rộng không thỏa hiệp trong hệ sinh thái Web3
Khả năng mở rộng và sự cân bằng: Polkadot tìm kiếm sự cân bằng trong hệ sinh thái Web3
Trong bối cảnh blockchain ngày càng tìm kiếm 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 để mở rộng hiệu suất mà không hy sinh tính bảo mật và tính đàn hồi 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à tính bảo mật, thường khó có thể hỗ trợ đổi mới thực sự bền vững.
Polkadot, như một động lực quan trọng cho khả năng mở rộng Web3, có phải đã hy sinh một số điều dưới 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ề tính phi tập trung, an ninh hay khả năng tương tác mạng? Bài viết này sẽ tập trung vào những vấn đề này, phân tích sâu sắc những lựa chọn và đánh đổi của Polkadot trong thiết kế khả năng mở rộng, đồng thời so sánh với các giải pháp của các chuỗi công khai khác, khám phá những lộ trình 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 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ể gây ra rủi ro tập trung trong một số khía cạnh? 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ác đặ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, giao tiếp 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 minh 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 hành.
Sự cân nhắc về mở rộng theo chiều 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 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 thực block rollup không được 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 tới 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 thực. Kẻ tấn công có thể lợi dụng điều này, gửi lại nhiều lần các khối hợp pháp đã được xác thực trước đó đến các core khác nhau, tiêu tốn tài nguyên một cách độc hại, từ đó giảm tổng khả năng xử lý 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.
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ụ, áp dụng cơ chế danh sách trắng, hoặc mặc định tin tưởng rằng các trình xếp hạng sẽ không có hành vi độc hại, từ đó đảm bảo tính khả dụng của rollup.
Tuy nhiên, trong thiết kế của Polkadot, chúng ta không thể đặt 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 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 thông tin đồng thuận duy nhất đáng tin cậy, do đó phải tuyên bố rõ ràng trong đầu ra nên thực hiện xác minh 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 việc phân bổ core thông qua giao thức kinh tế mã hóa ELVES.
Trước khi ghi dữ liệu vào lớp khả dụng của Polkadot (DA) trong bất kỳ khối rollup nào, 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ác biên lai ứng cử viên và bằng chứng hợp lệ do bộ sắp xếp gửi, bao gồm khối rollup và bằng chứng lưu trữ tương ứ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 xác thực trên chuỗi tiếp theo 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 để chỉ định nên xác minh khối trên core nào. Người xác minh sẽ so sánh chỉ số này với core mà họ 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 hành vi xấu từ các tác nhân như bộ điều chỉnh thao túng vị trí xác thực, đảm bảo ngay cả khi rollup sử dụng nhiều core cũng vẫn giữ được tính đàn hồi.
An toàn
Trong quá trình theo đuổi khả năng mở rộng, Polkadot không có bất kỳ sự thỏa hiệp nào về mặt an ninh. Sự an toàn của rollup được đảm bảo bởi chuỗi trung gian, chỉ cần một nhà sắp xếp trung thực là có thể duy trì sự sống.
Với 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 thực mọi phép toán trên core mà không cần 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 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 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à 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 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
Thông lượng cao hơn và độ trễ thấp hơn không thể tránh khỏi sẽ dẫn đến sự phức tạp, đây là cách duy nhất để 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 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 các yêu cầu RFC103 để phù hợp với các trường hợp 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ể 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 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 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 tin.
Giao tiếp tin nhắn 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 sẽ hỗ trợ truyền thông ngoài chuỗi, với chuỗi tiếp nối là 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ăng cường hơn nữa khả năng mở rộng theo chiều dọc của hệ thống.
Các giao thức khác đã thực hiện những sự đánh đổi nào?
Như mọi người đã biết, việc nâng cao hiệu suất thường phải hy sinh sự 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 hơn, hiệu suất của chúng cũng không được 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à thực hiện khả năng mở rộng bằng kiến trúc một lớp với hiệu suất cao, dựa vào bằng chứng lịch sử (PoH), xử lý song song CPU và cơ chế đồng thuận dựa trên lãnh đạo, với TPS lý thuyết có thể đạt tới 65,000.
Một thiết kế chính là cơ chế lập 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 số 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ó 1% cổ phần 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 bị sập.
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 chứng khoá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, càng làm trầm trọng thêm 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 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
Một dự án blockchain 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 cộng phi tập trung.
Cơ chế đồng thuận của dự án này 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ị lộ trước. Bản trắng giấy của nó 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ế "xổ số phá sản", kẻ tấn công có thể chờ đợi một phân đoạn nào đó hoàn toàn nằm trong sự kiểm soát của mình, hoặc thông qua tấn công DDoS để 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 trước, 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ộ để 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à khiến 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 X-Chain (chuyển khoả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 xác nhận viên tự do chọn tham gia subnet, và subnet có thể thiết lập các yêu cầu thêm về địa lý, KYC, v.v., hy sinh sự phi tập trung và an toàn.
Tại Polkadot, tất cả các rollup 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 toàn mặc định, một số thậm chí có thể hoàn toàn trung tâm hóa. 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 toàn có tính xác định.
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ề cơ bản không giải quyết được vấn đề, mà chỉ chuyển vấn đề lên tầng cao hơ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), gặp phải các vấn đề như thiếu an toàn, 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ị hạn chế 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 chứng minh không tri thức là 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 khối lượng giao dịch mỗi lô, và trong thời gian 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 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ử dụng 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 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à 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 blockchain công khai khác, Polkadot không chọn 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 niềm 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 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 ngày nay đang theo đuổi việc áp dụng quy mô lớn hơn, "mở rộng không cần 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 bền vững của Web3.