Vitalik: Các loại L2 khác nhau cùng trỗi dậy, ứng dụng và người dùng nên lựa chọn như thế nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik: Các loại L2 khác nhau cùng trỗi dậy, ứng dụng và người dùng nên lựa chọn như thế nào?
Đối với ứng dụng đã cho, trong các cân nhắc phức tạp giữa Rollup, Validium và các hệ thống khác thì phương án nào là phù hợp nhất?
Chuyên sâu báo cáo Web3Tác giả: Vitalik
Biên dịch: TechFlow
Hệ sinh thái lớp 2 của Ethereum đã mở rộng nhanh chóng trong năm qua. Hệ sinh thái ZK-EVM Rollup truyền thống từng nổi bật với StarkNet, Arbitrum, Optimism và Scroll, đang phát triển mạnh mẽ và đạt được tiến bộ đáng kể về bảo mật; L2beat tổng hợp tốt tình trạng hiện tại của từng dự án. Ngoài ra, chúng ta còn chứng kiến một số nhóm xây dựng sidechain bắt đầu chuyển sang xây dựng Rollup (Polygon), các dự án lớp 1 tìm cách tiến tới Validium (Celo), cùng những nỗ lực hoàn toàn mới (Linea, Zeth...).
Một hệ quả tất yếu của sự phát triển này là xu hướng đa dạng hóa ngày càng tăng trong các dự án lớp 2. Tôi dự đoán xu hướng này sẽ tiếp tục, vì một vài lý do then chốt:
-
Một số dự án hiện tại độc lập với lớp 1 đang tìm cách gắn kết hơn với hệ sinh thái Ethereum và có thể trở thành lớp 2. Những dự án này có thể muốn chuyển đổi dần dần. Việc chuyển toàn bộ ngay lập tức hiện nay sẽ làm giảm tính khả dụng, vì công nghệ chưa sẵn sàng để đưa mọi thứ lên Rollup. Trong khi đó, việc trì hoãn quá lâu rồi chuyển toàn bộ sẽ khiến họ đánh mất động lực và trở nên lỗi thời.
-
Một số dự án tập trung đang tìm cách cung cấp mức độ an toàn cao hơn cho người dùng, đang khám phá các con đường dựa trên blockchain. Trong nhiều trường hợp, trước đây họ đã từng xem xét đến “blockchain liên minh được phép”. Trên thực tế, họ có lẽ chỉ cần mức độ “bán tập trung” vừa phải. Hơn nữa, họ thường có thông lượng rất cao, ít nhất trong ngắn hạn không phù hợp để sử dụng Rollup.
-
Các ứng dụng phi tài chính như game hay mạng xã hội muốn phi tập trung hóa nhưng chỉ cần mức độ an toàn trung bình. Trong trường hợp mạng xã hội, điều này thực chất liên quan đến việc xử lý khác nhau các phần khác nhau của ứng dụng: 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 Rollup, nhưng các hoạt động thường xuyên và có giá trị thấp như đăng bài và bình chọn thì cần ít an toàn hơn. Nếu chuỗi bị lỗi khiến bài viết của bạn biến mất, đó là một cái giá chấp nhận được. Nhưng nếu chuỗi lỗi khiến bạn mất tài khoản, thì đó là vấn đề nghiêm trọng hơn nhiều.
Một chủ đề quan trọng là, mặc dù trong ngắn hạn các ứng dụng và người dùng hiện tại trên lớp 1 Ethereum sẽ sẵn sàng trả phí Rollup nhỏ nhưng vẫn thấy rõ, người dùng từ thế giới ngoài blockchain sẽ không chịu: nếu trước đây đã trả 1 đô la thì việc trả thêm 0,10 đô la là dễ chấp nhận, nhưng nếu trước đây không phải trả gì thì việc bắt đầu trả tiền lại khó chấp nhận hơn. Điều này không chỉ đúng với các ứng dụng tập trung hiện nay mà còn đúng với các lớp 1 nhỏ hơn, vốn thường có mức phí rất thấp khi cơ sở người dùng của họ vẫn còn nhỏ.
Một câu hỏi tự nhiên đặt ra là: đối với một ứng dụng cụ thể, lựa chọn nào trong số các cân nhắc phức tạp giữa Rollup, Validium và các hệ thống khác là phù hợp nhất?
Rollup so với Validium so với các hệ thống ngắt kết nối
Chiều kích đầu tiên giữa an toàn và quy mô mà chúng ta sẽ khám phá có thể mô tả như sau: Nếu bạn sở hữu tài sản được phát hành trên L1, sau đó gửi vào L2 rồi chuyển cho bạn, thì mức độ đảm bảo bạn có thể rút tài sản đó về L1 là bao nhiêu?
Cũng có một câu hỏi tương tự: lựa chọn kỹ thuật nào tạo nên mức độ đảm bảo này, và những đánh đổi của lựa chọn kỹ thuật đó là gì?
Chúng ta có thể đơn giản mô tả điều này bằng sơ đồ:
Cần lưu ý rằng đây là một mô hình đơn giản hóa, tồn tại nhiều lựa chọn trung gian. Ví dụ:
-
Giữa Rollup và Validium: Validium cho phép bất kỳ ai thanh toán phí giao dịch trên chuỗi, lúc đó nhà vận hành buộc phải đưa một số dữ liệu lên chuỗi, nếu không sẽ mất khoản tiền gửi.
-
Giữa Plasma và Validium: Hệ thống Plasma cung cấp đảm bảo an toàn giống Rollup, với khả năng truy cập dữ liệu ngoài chuỗi, nhưng chỉ hỗ trợ một số lượng hạn chế ứng dụng. Một hệ thống có thể cung cấp EVM đầy đủ, đồng thời cung cấp đảm bảo mức Plasma cho người dùng không sử dụng các ứng dụng phức tạp hơn, và đảm bảo mức Validium cho người dùng sử dụng các ứng dụng phức tạp hơn.
Những lựa chọn trung gian này có thể được xem là nằm giữa Rollup và kiểm chứng. Nhưng điều gì thúc đẩy một ứng dụng chọn một điểm cụ thể ở hai đầu thay vì một điểm nào đó lệch trái hoặc phải hơn? Tại đây, có hai yếu tố chính:
-
Chi phí khả năng truy cập dữ liệu gốc của Ethereum, đang dần giảm xuống khi công nghệ cải thiện. Bản nâng cấp cứng tiếp theo của Ethereum, Dencun, sẽ giới thiệu EIP-4844 (còn gọi là "proto-danksharding"), cung cấp khoảng 32 kB khả năng truy cập dữ liệu trên chuỗi mỗi giây. Trong vài năm tới, dự kiến sẽ tăng dần theo từng giai đoạn, với mục tiêu cuối cùng khi triển khai đầy đủ danksharding là khoảng 1,3 MB dữ liệu mỗi giây. Đồng thời, các cải tiến về nén dữ liệu sẽ giúp chúng ta làm được nhiều việc hơn với cùng lượng dữ liệu.
-
Nhu cầu riêng của ứng dụng: Người dùng bị ảnh hưởng bởi phí cao hay bởi sự cố của ứng dụng? Các ứng dụng tài chính sẽ chịu tổn thất lớn hơn nếu ứng dụng gặp lỗi; các trò chơi và mạng xã hội liên quan đến lượng lớn hoạt động người dùng với giá trị tương đối thấp, do đó các cân nhắc an toàn khác nhau là hợp lý đối với chúng.
Nói chung, sự đánh đổi này trông như thế này:
Một loại đảm bảo một phần đáng chú ý khác là xác nhận trước (pre-confirmations). Xác nhận trước là tin nhắn được ký bởi một số bên tham gia trong Rollup hoặc Validium, tuyên bố rằng “Chúng tôi xác nhận các giao dịch này được bao gồm trong thứ tự này và root trạng thái sau là giá trị này”. Những người tham gia này có thể ký một xác nhận trước không phù hợp với thực tế sau này, nhưng nếu họ làm vậy, khoản tiền gửi của họ sẽ bị thiêu rụi. Điều này rất hữu ích đối với các ứng dụng giá trị thấp như thanh toán tiêu dùng, trong khi các ứng dụng giá trị cao như chuyển tiền tài chính hàng triệu đô la có thể chờ xác nhận “thông thường” được hỗ trợ bởi tính an toàn đầy đủ của hệ thống.
Xác nhận trước có thể được xem như một ví dụ khác về hệ thống lai, tương tự như kiểu “lai plasma/validium” đã đề cập ở trên, nhưng lần này là sự kết hợp giữa Rollup (hoặc Validium) có tính an toàn đầy đủ nhưng độ trễ cao với hệ thống có mức độ an toàn thấp hơn nhưng độ trễ thấp hơn. Các ứng dụng cần độ trễ thấp hơn sẽ chấp nhận mức an toàn thấp hơn, nhưng vẫn có thể tồn tại trong cùng hệ sinh thái với những ứng dụng sẵn sàng chấp nhận độ trễ cao hơn để đổi lấy mức an toàn tối đa.
Đọc Ethereum một cách không cần tin tưởng
Một dạng kết nối khác ít được bàn luận hơn nhưng vẫn rất quan trọng liên quan đến khả năng của hệ thống trong việc đọc chuỗi khối Ethereum. Đặc biệt, điều này bao gồm khả năng hoàn tác khi Ethereum hoàn tác. Để 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 vẽ, chuỗi Ethereum bị hoàn tác. Điều này có thể là một lỗi tạm thời trong một kỷ nguyên, khi chuỗi chưa được xác nhận cuối cùng, hoặc có thể là giai đoạn tê liệt khi chuỗi liên tục hồi phục do quá nhiều trình xác thực ngoại tuyến.
Điều tồi tệ nhất có thể xảy ra như sau. Giả sử dữ liệu từ khối ngoài cùng bên trái của chuỗi Ethereum được đọc vào khối đầu tiên của chuỗi phía trên. Ví dụ, ai đó đã gửi 100 ETH từ Ethereum vào chuỗi phía trên. Sau đó, Ethereum bị hoàn tác. Tuy nhiên, chuỗi phía trên không hoàn tác. Kết quả là, các khối tương lai của chuỗi phía trên tuân theo đúng các khối mới của chuỗi Ethereum mới, nhưng hậu quả sai lầm từ liên kết cũ (tức là khoản gửi 100 ETH) vẫn tồn tại trong chuỗi phía trên. Lỗ hổng này có thể cho phép in tiền, biến ETH được cầu nối trên chuỗi phía trên thành dự trữ một phần.
Có hai cách giải quyết vấn đề này:
-
Chuỗi phía trên chỉ có thể đọc các khối đã được xác nhận cuối cùng của Ethereum, do đó nó sẽ không bao giờ cần phải hoàn tác.
-
Nếu Ethereum hoàn tác, chuỗi phía trên cũng nên hoàn tác. Cả hai phương pháp đều ngăn chặn được vấn đề này. Phương pháp đầu tiên dễ triển khai hơn, nhưng nếu Ethereum rơi vào tình trạng tê liệt, có thể dẫn đến mất chức năng trong thời gian dài. Phương pháp thứ hai khó triển khai hơn, nhưng đảm bảo luôn duy trì chức năng tốt nhất.
Lưu ý rằng phương pháp đầu tiên (1) thực ra có một trường hợp đặc biệt. Nếu Ethereum bị tấn công 51% tạo ra hai khối mới không tương thích đồng thời hiển thị là đã được xác nhận cuối cùng, chuỗi phía trên có khả năng cao sẽ bị khóa vào khối sai (khối mà cộng đồng Ethereum về mặt xã hội không ủng hộ), và phải hoàn tác để chuyển sang khối đúng. Có thể lập luận rằng không cần viết mã xử lý tình huống này sớm; nó có thể được xử lý bằng hard fork chuỗi phía trên.
Khả năng đọc Ethereum một cách không cần tin tưởng của một chuỗi có hai lý do:
-
Nó làm giảm các vấn đề an toàn liên quan đến việc cầu nối các token được phát hành trên Ethereum (hoặc L2 khác)
-
Nó cho phép ví trừu tượng tài khoản sử dụng kiến trúc kho khóa chung an toàn giữ tài sản trên chuỗi đó.
Cả hai khía cạnh này đều rất quan trọng, mặc dù có thể tranh luận rằng nhu cầu này đã được công nhận rộng rãi. Khía cạnh thứ hai cũng rất quan trọng vì nó có nghĩa là bạn có thể sở hữu một ví cho phép dễ dàng thay đổi khóa và giữ tài sản trên nhiều chuỗi khác nhau.
Việc sở hữu một cầu nối có làm bạn trở thành Validium?
Giả sử chuỗi phía trên ban đầu là một chuỗi độc lập, sau đó có người triển khai một hợp đồng cầu nối trên Ethereum. Hợp đồng cầu nối chỉ đơn giản là một hợp đồng chấp nhận tiêu đề khối của chuỗi phía trên, xác minh xem tiêu đề khối nào được gửi có đi kèm chứng chỉ hợp lệ cho thấy nó đã được chấp nhận bởi cơ chế đồng thuận của chuỗi phía trên hay không, và thêm tiêu đề đó vào danh sách. Các ứng dụng có thể xây dựng trên nền tảng này để thực hiện chức năng gửi/rút token, v.v. Một khi có cầu nối như vậy, liệu nó có cung cấp bất kỳ đảm bảo an toàn tài sản nào mà chúng ta đã đề cập trước đây không?
Cho đến nay, câu trả lời là chưa, vì hai lý do:
-
Chúng ta đang xác minh khối đã được ký, nhưng chưa xác minh chuyển đổi trạng thái có đúng hay không. Do đó, nếu bạn gửi tài sản phát hành trên Ethereum vào chuỗi phía trên, và các trình xác thực của chuỗi phía trên trở nên bất chính, 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 đó.
-
Chuỗi phía trên vẫn không thể đọc Ethereum. Vì vậy, thậm chí không thể gửi tài sản gốc của Ethereum vào chuỗi phía trên, mà phải phụ thuộc vào một cầu nối bên thứ ba khác (có thể không an toàn).
Bây giờ, hãy biến hợp đồng cầu nối thành một cầu nối xác minh: nó không chỉ kiểm tra cơ chế đồng thuận mà còn thực hiện xác minh ZK-SNARK để đảm bảo trạng thái của mọi khối mới được tính toán đúng.
Một khi làm được điều này, các trình xác thực của chuỗi phía trên sẽ không thể đánh cắp tiền của bạn. Họ có thể xuất bản một khối 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 (trừ khi cố gắng cung cấp dữ liệu cho phép người dùng rút tiền để đổi lấy tiền chuộc). Mô hình an toàn này giống với Validium.
Tuy nhiên, vấn đề thứ hai vẫn chưa được giải quyết: chuỗi phía trên không thể đọc Ethereum.
Để giải quyết vấn đề này, chúng ta cần thực hiện một trong hai thao tác sau:
-
Đặt một hợp đồng cầu nối bên trong chuỗi phía trên để xác minh các khối Ethereum đã được xác nhận cuối cùng.
-
Yêu cầu mỗi khối trong chuỗi phía trên chứa hash của khối Ethereum gần đây nhất, và thiết lập một quy tắc lựa chọn phân nhánh buộc phải tuân thủ liên kết hash. Nghĩa là, khối chuỗi phía trên liên kết với khối Ethereum không nằm trong chuỗi chuẩn thì bản thân khối đó cũng không phải là chuẩn; và nếu khối chuỗi phía trên liên kết với khối Ethereum ban đầu là chuẩn nhưng sau đó trở thành không chuẩn, thì khối chuỗi phía trên cũng phải trở thành không chuẩn.
Liệu điều này đã đủ chưa? Hóa ra vẫn chưa đủ, vì còn tồn tại một vài trường hợp biên nhỏ:
-
Nếu Ethereum bị tấn công 51% thì sao?
-
Làm thế nào để xử lý các bản nâng cấp hard fork của Ethereum?
-
Làm thế nào để xử lý các bản nâng cấp hard fork của chính chuỗi bạn?
Tấn công 51% đối với Ethereum sẽ tạo ra hậu quả tương tự như tấn công 51% đối với chuỗi phía trên, nhưng ngược lại. Hard fork của Ethereum có thể khiến cầu nối Ethereum bên trong chuỗi phía trên không còn hiệu lực. Cách rõ ràng nhất để giải quyết vấn đề này là thiết lập một cam kết xã hội rằng nếu Ethereum hoàn tác các khối đã được xác nhận cuối cùng, hoặc nếu Ethereum hard fork, thì chuỗi phía trên cũng sẽ hoàn tác. Cam kết này có thể sẽ không bao giờ cần thực hiện thực tế: nếu công cụ quản trị trên chuỗi phía trên thấy dấu hiệu bị tấn công hoặc hard fork, nó có thể được kích hoạt, chỉ hard fork chuỗi phía trên khi công cụ quản trị thất bại.
Với câu hỏi (3), câu trả lời khả thi duy nhất, thật đáng tiếc, là phải có một dạng công cụ quản trị trên Ethereum, để hợp đồng cầu nối trong Ethereum có thể nhận thức được các bản nâng cấp hard fork của chuỗi phía trên.
Tóm lại: cầu nối hai chiều có xác minh gần như đủ để biến một chuỗi thành Validium. Yếu tố chính còn lại là một cam kết xã hội rằng nếu Ethereum xảy ra trường hợp đặc biệt khiến cầu nối không còn hiệu lực, chuỗi kia sẽ phản ứng bằng hard fork.
Kết luận
“Kết nối với Ethereum” có hai chiều then chốt:
-
Tính an toàn khi rút tiền về Ethereum;
-
Tính an toàn khi đọc Ethereum.
Cả hai yếu tố này đều quan trọng và có các cân nhắc khác nhau:
Lưu ý rằng mỗi chiều này có hai cách đo lường khác nhau (vì vậy thực tế là bốn chiều): tính an toàn khi rút tiền có thể được đo bằng (i) mức độ an toàn và (ii) số lượng người dùng hoặc trường hợp sử dụng được hưởng lợi từ mức an toàn cao nhất; trong khi tính an toàn khi đọc có thể được đo bằng (i) tốc độ chuỗi có thể đọc khối Ethereum, đặc biệt là khối đã được xác nhận cuối cùng so với bất kỳ khối nào, và (ii) sức mạnh của cam kết xã hội về việc xử lý các trường hợp biên như tấn công 51% và hard fork.
Nhiều khu vực trong không gian thiết kế này đều có giá trị cho các dự án. Với một số ứng dụng, an toàn cao và kết nối chặt chẽ là then chốt. Với các ứng dụng khác, các giải pháp linh hoạt hơn có thể chấp nhận được để đạt được khả năng mở rộng lớn hơn. Trong nhiều trường hợp, bắt đầu với giải pháp linh hoạt hơn từ hôm nay và chuyển dần sang liên kết chặt chẽ hơn trong thập kỷ tới khi công nghệ cải thiện có lẽ là lựa chọn tốt nhất.
Có thể bạn muốn đọc: Ghi chú现场 tại ETH HK: Vitalik nói gì về thách thức và tương lai của Ethereum? - TechFlow
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
