Vitalik: Phân tích sự khác biệt giữa các loại L2

Các dự án L2 sẽ ngày càng có xu hướng dị thể hóa.

Tiêu đề gốc: 《Different types of layer 2s》

Tác giả: Vitalik Buterin

Biên dịch: BlockBeats

Hệ sinh thái đã mở rộng nhanh chóng trong năm qua. Truyền thống, hệ sinh thái ZK-EVM rollup do StarkNet, Arbitrum, Optimism và Scroll đại diện đã tiến triển nhanh chóng, liên tục nâng cao tính bảo mật của mình, trang L2beat đã tổng kết rất tốt trạng thái của từng dự án.

Bên cạnh đó, chúng ta còn thấy một số nhóm đang xây dựng sidechain đồng thời cũng bắt đầu phát triển giải pháp rollup (như Polygon), một số dự án L1 đang cố gắng chuyển hướng sang xác thực tính hợp lệ (như Celo), và còn có những thử nghiệm hoàn toàn mới (như Linea, Zeth…).

Một trong những kết quả không thể tránh khỏi là chúng ta thấy các dự án L2 có xu hướng trở nên ngày càng heterogeneous (dị thể hóa). (Chú thích của dịch giả: Trong lĩnh vực crypto, “dị thể hóa” chỉ việc các loại hoặc bản chất khác nhau cùng tồn tại hoặc trộn lẫn với nhau. Thuật ngữ này thường dùng để mô tả các blockchain, giao thức, công nghệ hoặc tài sản khác nhau có đặc tính, quy tắc hoặc thuộc tính khác nhau.) Tôi dự đoán xu hướng này sẽ tiếp tục vì các lý do sau:

Hiện tại, một số dự án L1 độc lập đang tìm cách tiếp cận gần hơn với hệ sinh thái Ethereum và có khả năng chuyển đổi thành dự án L2. Những dự án này có thể muốn thực hiện quá trình chuyển đổi theo từng giai đoạn. Chuyển đổi toàn bộ ngay lập tức sẽ làm giảm khả năng sử dụng vì công nghệ chưa sẵn sàng để đưa mọi thứ vào giải pháp rollup. Còn nếu chuyển đổi toàn bộ quá muộn, có thể sẽ đánh mất động lực và không kịp tạo ra ý nghĩa thực tế.

Một số dự án tập trung muốn cung cấp thêm bảo đảm an toàn cho người dùng và đang khám phá các phương án dựa trên blockchain. Trong nhiều trường hợp, các dự án này trước đây có thể đã nghiên cứu “chuỗi liên minh có phép”. Thực tế, họ chỉ cần đạt đến mức “bán phi tập trung”. Ngoài ra, họ thường có thông lượng rất cao, ít nhất trong ngắn hạn không phù hợp với giải pháp rollup.

Các ứng dụng phi tài chính như game hoặc mạng xã hội muốn phi tập trung hóa, nhưng chỉ cần một mức độ bảo mật nhất định.

Trong trường hợp mạng xã hội, thực tế liên quan đến việc xử lý các phần khác nhau của ứng dụng theo cách khác nhau: các hoạt động hiếm gặp và có giá trị cao như đăng ký tên người dùng và khôi phục tài khoản nên được thực hiện trên giải pháp rollup, còn các hoạt động thường xuyên và giá trị thấp như đăng bài và bình chọn chỉ cần mức bảo mật thấp hơn, nếu blockchain gặp sự cố khiến bài đăng của bạn biến mất thì đó là cái giá có thể chấp nhận được; nhưng nếu blockchain gặp sự cố khiến bạn mất tài khoản thì đó là vấn đề lớn hơn.

Một chủ đề quan trọng là, mặc dù các ứng dụng và người dùng hiện đang ở trên Ethereum L1 sẵn sàng trả một khoản phí rollup nhỏ nhưng vẫn thấy rõ, nhưng người dùng đến từ thế giới ngoài blockchain lại ít sẵn sàng làm như vậy: nếu bạn từng trả 1 USD thì trả 0,10 USD sẽ dễ chấp nhận hơn, còn nếu trước đó bạn trả 0 USD thì sẽ rất khó chấp nhận.

Điều này áp dụng cho các ứng dụng hiện vẫn tập trung, cũng như các dự án L1 nhỏ thường có phí cực thấp khi quy mô người dùng còn nhỏ.

Một câu hỏi tự nhiên là: Đối với một ứng dụng cụ thể, trong những sự đánh đổi phức tạp giữa giải pháp rollup, validium (xác thực tính hợp lệ) và các hệ thống khác, đâu là lựa chọn hợp lý nhất?

Rollups vs Validiums vs Disconnected Systems

Chúng ta sẽ khám phá chiều đầu tiên của bảo mật và khả năng mở rộng, có thể mô tả như sau: Nếu bạn sở hữu một tài sản phát hành trên L1, sau đó gửi nó vào L2, rồi chuyển nó vào tay bạn, thì bạn có thể đảm bảo ở mức độ nào rằng có thể rút tài sản đó về L1?

Đồng thời còn có một câu hỏi liên quan: Lựa chọn công nghệ nào dẫn đến mức độ đảm bảo này, và sự đánh đổi của lựa chọn đó là gì?

Chúng ta có thể mô tả vấn đề này bằng một biểu đồ đơn giản:

Đáng chú ý là đây là một sơ đồ đơn giản hóa, thực tế tồn tại nhiều lựa chọn trung gian. Ví dụ:

Giữa rollup và validium: Trong validium, bất kỳ ai cũng có thể thanh toán phí giao dịch trên chuỗi, khi đó, nhà vận hành sẽ buộc phải cung cấp một số dữ liệu lên chuỗi, nếu không sẽ mất tiền ký quỹ.

Giữa plasma và validium: Một hệ thống Plasma cung cấp bảo đảm an toàn tương tự rollup với dữ liệu khả dụng ngoài chuỗi, nhưng chỉ hỗ trợ số lượng ứng dụng hạn chế. Một hệ thống có thể cung cấp đầy đủ EVM, và với những người dùng không sử dụng các ứng dụng phức tạp hơn này sẽ nhận được bảo đảm cấp Plasma, còn người dùng sử dụng các ứng dụng này sẽ nhận được bảo đảm cấp validium.

Những lựa chọn trung gian này có thể xem là nằm trên một phổ giữa rollup và validium. Nhưng điều gì thúc đẩy ứng dụng chọn điểm cụ thể nào trên phổ này, thay vì lệch sang trái hay phải hơn? Ở đây có hai yếu tố chính:

1. Chi phí khả dụng dữ liệu gốc của Ethereum, chi phí này sẽ giảm dần theo thời gian khi công nghệ phát triển. Đợt hard fork tiếp theo của Ethereum là Dencun sẽ giới thiệu EIP-4844 (hay còn gọi là “proto-danksharding”), cung cấp khoảng 32 kB/giây khả dụng dữ liệu trên chuỗi.

Dự kiến trong vài năm tới, khi danksharding hoàn chỉnh được triển khai, khả dụng dữ liệu này sẽ tăng dần, mục tiêu cuối cùng là khoảng 1,3 MB/giây. Đồng thời, cải tiến nén dữ liệu sẽ giúp chúng ta thực hiện được nhiều chức năng hơn với cùng lượng dữ liệu.

2. Nhu cầu của chính ứng dụng: Thiệt hại của người dùng khi phí cao so với thiệt hại khi ứng dụng gặp sự cố nghiêm trọng đến mức nào? Ứng dụng tài chính sẽ thiệt hại nhiều hơn nếu ứng dụng gặp sự cố; game và mạng xã hội liên quan đến lượng lớn hoạt động người dùng và giá trị tương đối thấp, nên với chúng, các đánh đổi bảo mật khác nhau là hợp lý.

Sự đánh đổi này về cơ bản trông như sau:

Một loại hình khác cũng đáng nhắc đến là xác nhận trước (pre-confirmations). Xác nhận trước là thông điệp được một nhóm người tham gia ký trong rollup hoặc validium, thể hiện rằng “chúng tôi xác nhận các giao dịch này được đưa vào theo thứ tự này, và post-state root là như vậy”. Những người tham gia này có thể ký một xác nhận trước không đúng thực tế, nhưng nếu làm vậy, tiền ký quỹ của họ sẽ bị tiêu hủy.

Điều này rất hữu ích cho các ứng dụng giá trị thấp (như thanh toán tiêu dùng), còn các ứng dụng giá trị cao (như chuyển khoản tài chính hàng triệu USD) có thể chờ xác nhận “thông thường” được hỗ trợ bởi tính bảo mật đầy đủ của hệ thống.

Xác nhận trước có thể xem là một ví dụ khác về hệ thống lai, tương tự như “lai plasma/validium” đã đề cập ở trên, nhưng lần này là sự pha trộn giữa rollup (hoặc validium) có bảo mật đầy đủ nhưng độ trễ cao với hệ thống có bảo mật thấp hơn nhưng độ trễ thấp. Các ứng dụng cần độ trễ thấp sẽ nhận được bảo mật thấp hơn, nhưng có thể cùng tồn tại trong hệ sinh thái với các ứng dụng sẵn sàng chịu độ trễ cao để đổi lấy bảo mật tối đa.

Đọc Ethereum một cách không cần tin cậy

Một hình thức kết nối khác ít được chú ý hơn nhưng vẫn rất quan trọng, liên quan đến khả năng hệ thống đọc blockchain Ethereum. Cụ thể, điều này bao gồm khả năng hệ thống có thể quay lại (rollback) khi Ethereum xảy ra rollback. Để hiểu tại sao điều này có giá trị, hãy xem xét tình huống sau:

Giả sử như hình, blockchain Ethereum xảy ra rollback. Điều này có thể là sự gián đoạn tạm thời trong một epoch, khi blockchain chưa được xác nhận cuối cùng; hoặc có thể là do quá nhiều validator offline, dẫn đến blockchain không thể xác nhận cuối cùng trong thời gian dài (giai đoạn leakage không hoạt động).

Kịch bản xấu nhất có thể xảy ra như sau: giả sử block đầu tiên của chuỗi trên cùng (top chain) đọc một số dữ liệu từ block ngoài cùng bên trái của chuỗi Ethereum. Ví dụ, ai đó gửi 100 ETH trên Ethereum vào chuỗi trên cùng. Sau đó Ethereum rollback, nhưng chuỗi trên cùng không rollback. Kết quả là, các block tiếp theo của chuỗi trên cùng vẫn theo đúng các block mới, đúng của chuỗi Ethereum, nhưng giao dịch sai (tức là khoản gửi 100 ETH) vẫn tồn tại trên chuỗi trên cùng. Lỗ hổng này có thể dẫn đến phát hành tiền vượt mức, biến ETH bridge trên chuỗi trên cùng thành dự trữ một phần.

Có hai cách để giải quyết vấn đề này:

1. Chuỗi trên cùng chỉ đọc các block đã xác nhận cuối cùng của Ethereum, do đó không bao giờ cần rollback;

2. Nếu Ethereum rollback, chuỗi trên cùng cũng có thể rollback. Cả hai đều có thể ngăn chặn vấn đề này. Cách đầu tiên dễ triển khai hơn, nhưng nếu Ethereum rơi vào giai đoạn leakage không hoạt động, có thể khiến chức năng bị mất trong thời gian dài. Cách thứ hai khó triển khai hơn, nhưng đảm bảo luôn có chức năng tối ưu.

Lưu ý rằng cách đầu tiên thực sự có một trường hợp đặc biệt. Nếu Ethereum bị tấn công 51%, dẫn đến hai block mới không tương thích cùng xuất hiện, cả hai đều trông như đã xác nhận cuối cùng, thì chuỗi trên cùng có thể chọn nhầm block (tức là block không được đồng thuận xã hội của Ethereum ủng hộ cuối cùng), và cần rollback để chuyển sang block đúng. Có thể nói, không cần viết sẵn code xử lý trường hợp này; có thể xử lý bằng cách hard fork chuỗi trên cùng.

Khả năng blockchain đọc Ethereum một cách không cần tin cậy có hai lý do quan trọng:

Thứ nhất, khả năng này có thể giảm rủi ro bảo mật khi bridge token phát hành trên Ethereum (hoặc các giải pháp layer 2 khác) sang chuỗi đó;

Thứ hai, khả năng này cho phép ví tài khoản trừu tượng sử dụng cấu trúc lưu trữ khóa chung có thể giữ tài sản trên chuỗi đó một cách an toàn.

Dù còn gây tranh cãi, nhưng tầm quan trọng của cách đầu tiên đã được công nhận rộng rãi. Tương tự, cách thứ hai cũng rất quan trọng, vì nó cho phép bạn có một ví có thể dễ dàng thay đổi khóa và giữ tài sản trên nhiều chuỗi khác nhau.

Sở hữu bridge có thể trở thành validium không?

Giả sử chuỗi trên cùng ban đầu được khởi chạy như một chuỗi độc lập, sau đó ai đó triển khai một hợp đồng bridge trên Ethereum. Hợp đồng bridge chỉ là một hợp đồng nhận block header của chuỗi trên cùng, nó sẽ xác minh bất kỳ block header nào gửi đến có kèm chứng chỉ hợp lệ chứng minh block header đó đã được đồng thuận của chuỗi trên cùng chấp nhận, và thêm block header đó vào danh sách.

Ứng dụng có thể xây dựng các chức năng như gửi và rút token dựa trên đó. Một khi bridge như vậy được thiết lập, liệu nó có cung cấp bất kỳ bảo đảm an toàn tài sản nào như đã đề cập trước đó không?

Cho đến nay, vẫn chưa! Có hai lý do:

1. Chúng ta chỉ xác minh chữ ký của block, nhưng không xác minh chuyển đổi trạng thái có đúng không. Do đó, nếu bạn gửi tài sản phát hành trên Ethereum vào chuỗi trên cùng, và validator của chuỗi trên cùng trở nên không trung thực, họ có thể ký một chuyển đổi trạng thái không hợp lệ để đánh cắp tài sản đó;

2. Chuỗi trên cùng vẫn không thể đọc Ethereum. Do đó, bạn không thể gửi tài sản gốc Ethereum vào chuỗi trên cùng, trừ khi dựa vào bridge của bên thứ ba khác (có thể không an toàn).

Bây giờ, hãy xây dựng bridge thành bridge xác thực: nó không chỉ xác minh đồng thuận mà còn xác minh bất kỳ block mới nào được tính toán bằng bằng chứng ZK-SNARK đều có trạng thái hợp lệ.

Một khi hoàn thành bước này, validator của chuỗi trên cùng sẽ không thể đánh cắp tiền của bạn. Họ có thể xuất bản một block chứa dữ liệu không khả dụng, ngăn mọi người rút tiền, nhưng họ không thể đánh cắp tiền (trừ khi cố gắng đòi tiền chuộc để tiết lộ dữ liệu cho phép rút tiền). Điều này có cùng mô hình bảo mật với validium.

Tuy nhiên, chúng ta vẫn chưa giải quyết được vấn đề thứ hai: chuỗi trên cùng không thể đọc dữ liệu Ethereum. Để làm được điều này, chúng ta cần thực hiện một trong hai cách sau:

1. Đặt một hợp đồng bridge xác minh block Ethereum đã xác nhận cuối cùng trong chuỗi trên cùng;

2. Bao gồm hash của một block Ethereum gần nhất trong mỗi block của chuỗi trên cùng, và áp dụng quy tắc chọn fork để buộc liên kết hash. Tức là, block chuỗi trên cùng liên kết đến block Ethereum không thuộc chuỗi chính thì bản thân block chuỗi trên cùng cũng không thuộc chuỗi chính. Nếu block chuỗi trên cùng liên kết đến block Ethereum ban đầu thuộc chuỗi chính nhưng sau đó trở thành không thuộc chuỗi chính, block chuỗi trên cùng cũng phải trở thành không thuộc chuỗi chính.

Những liên kết màu tím này có thể là liên kết hash hoặc hợp đồng bridge xác minh đồng thuận Ethereum

Như vậy đã đủ chưa? Thực tế vẫn chưa, vì còn một số trường hợp biên nhỏ:

1. Nếu Ethereum bị tấn công 51% thì sao?

2. Làm thế nào để xử lý nâng cấp hard fork của Ethereum?

3. Làm thế nào để xử lý nâng cấp hard fork của chuỗi của bạn?

Tấn công 51% vào Ethereum sẽ dẫn đến hậu quả tương tự như tấn công 51% vào chuỗi trên cùng, nhưng ngược lại. Hard fork của Ethereum có thể khiến bridge Ethereum trong chuỗi trên cùng bị vô hiệu. Một cam kết xã hội, tức là nếu Ethereum hoàn nguyên một block đã xác nhận cuối cùng thì cũng hoàn nguyên, nếu Ethereum hard fork thì cũng hard fork, là cách giải quyết sạch nhất cho vấn đề này.

Cam kết như vậy thực tế có thể không bao giờ cần thực hiện thực tế: nếu cơ quan quản trị chuỗi trên cùng phát hiện bằng chứng có thể xảy ra tấn công hoặc hard fork, có thể kích hoạt cơ quan quản trị, chỉ khi cơ quan quản trị thất bại mới hard fork chuỗi trên cùng.

Đối với vấn đề thứ ba, câu trả lời khả thi duy nhất là thiết lập một hình thức quản trị nào đó trên Ethereum, để bridge contract trên Ethereum có thể nhận biết nâng cấp hard fork của chuỗi trên cùng.

Tóm lại: Bridge xác thực hai chiều gần như đủ để blockchain trở thành validium. Yếu tố chính còn lại là một cam kết xã hội, tức là nếu Ethereum xảy ra sự cố khiến bridge contract không hoạt động bình thường, blockchain còn lại sẽ hard fork để phản hồi.

Kết luận

“Kết nối với Ethereum” có hai chiều quan trọng:

1. Bảo mật khi rút về Ethereum;

2. Bảo mật khi đọc Ethereum.

Cả hai đều rất quan trọng và có các yếu tố cần cân nhắc khác nhau. Trong cả hai trường hợp đều tồn tại một phổ liên tục:

Lưu ý rằng mỗi chiều đều có hai cách đo lường khác nhau (thực tế là bốn chiều): Bảo mật rút có thể đo bằng (i) mức độ bảo mật, và (ii) bao nhiêu người dùng hoặc trường hợp sử dụng được hưởng mức bảo mật cao nhất;

Còn bảo mật đọc có thể đo bằng (i) chuỗi có thể đọc block Ethereum nhanh đến mức nào, đặc biệt là sự khác biệt giữa block đã xác nhận cuối cùng và bất kỳ block nào, và (ii) mức độ cam kết xã hội khi xử lý các trường hợp biên như tấn công 51% và hard fork.

Ở nhiều vùng trong không gian thiết kế này đều có giá trị cho dự án. Với một số ứng dụng, bảo mật cao và kết nối chặt chẽ là rất quan trọng. Với các ứng dụng khác, để có khả năng mở rộng lớn hơn, có thể chấp nhận điều kiện lỏng lẻo hơn. Trong nhiều trường hợp, bắt đầu với điều kiện lỏng lẻo hơn từ hôm nay, rồi dần chuyển sang kết nối chặt chẽ hơn trong thập kỷ tới khi công nghệ cải thiện có thể là lựa chọn tối ưu.