Vitalik: Layer3 nào thì có ý nghĩa?

Viết bởi: Vitalik, 《What kind of layer 3s make sense?》

Biên dịch: Đổng Nhất Minh, ChainCatcher

Đặc biệt cảm ơn Georgios Konstantopoulos, Karl Floersch và đội ngũ Starkware đã phản hồi và xem xét.

Một chủ đề thường xuất hiện trong các cuộc thảo luận về mở rộng layer 2 là khái niệm "layer 3s". Nếu chúng ta có thể xây dựng một giao thức layer 2 được neo vào layer 1 với mục đích chính là đảm bảo an toàn và tăng cường khả năng mở rộng, thì chắc chắn chúng ta cũng có thể mở rộng quy mô bằng cách xây dựng một giao thức layer 3 "neo vào layer 2 để đảm bảo an toàn và tăng cường khả năng mở rộng hơn nữa"?

Một phiên bản đơn giản của ý tưởng này là: nếu bạn có một giải pháp cho phép bạn đạt được tăng trưởng bình phương, bạn có thể xếp chồng giải pháp này lên chính nó và đạt được tăng trưởng theo cấp số nhân không? Những ý tưởng tương tự bao gồm bài viết về khả năng mở rộng của tôi vào năm 2015 và các mở rộng đa lớp được đề cập trong bài báo Plasma. Thật không may, khái niệm layer 3s đơn giản như vậy lại không dễ dàng hình thành thành một giải pháp khả thi. Do hạn chế về khả năng truy cập dữ liệu, sự phụ thuộc vào băng thông layer 1 cho việc rút tiền khẩn cấp hoặc nhiều vấn đề khác, luôn có một số thứ trong thiết kế không thể xếp chồng lên nhau và chỉ có thể mang lại cho bạn một lần nâng cao khả năng mở rộng.

Những ý tưởng mới hơn xung quanh layer 3s, như khung do Starkware đề xuất, phức tạp hơn: chúng không chỉ đơn thuần là xếp chồng những thứ giống nhau lên nhau, mà còn phân bổ các mục đích khác nhau cho layer 2 và layer 3. Nếu được thực hiện theo cách đúng đắn, hình thức tiềm năng của phương pháp này có thể khả thi. Bài viết này sẽ đi sâu vào những gì có thể có ý nghĩa trong kiến trúc ba lớp và những gì có thể không có ý nghĩa.

Tại sao bạn không thể duy trì khả năng mở rộng bằng cách xếp chồng rollups lên rollups?

Rollups (xem bài viết dài của tôi tại đây) là một công nghệ mở rộng, kết hợp nhiều công nghệ khác nhau để giải quyết hai nút thắt mở rộng chính trong việc vận hành blockchain: tính toán và dữ liệu. Tính toán đã được giải quyết bằng cách sử dụng "bằng chứng gian lận" hoặc SNARK, chúng phụ thuộc vào một số ít người tham gia để xử lý và xác minh mỗi khối, yêu cầu những người khác chỉ thực hiện một lượng tính toán nhỏ để kiểm tra xem quá trình chứng minh có hoàn thành đúng cách hay không. Những giải pháp này, đặc biệt là SNARK, có thể mở rộng gần như vô hạn; chúng ta có thể tiếp tục tạo ra "nhiều SNARK của SNARK" để giảm thiểu nhiều tính toán thành một bằng chứng duy nhất.

Dữ liệu thì khác. Rollups sử dụng một loạt các kỹ thuật nén để giảm lượng dữ liệu cần lưu trữ trên chuỗi cho các giao dịch: chuyển tiền đơn giản giảm từ khoảng 100 byte xuống còn khoảng 16 byte, chuyển ERC20 trong chuỗi tương thích EVM giảm từ khoảng 180 byte xuống khoảng 23 byte, một giao dịch ZK-SNARK bảo vệ quyền riêng tư có thể giảm từ khoảng 600 byte xuống còn khoảng 80 byte. Trong tất cả các trường hợp, có khoảng 8 lần nén. Tuy nhiên, rollup vẫn cần làm cho dữ liệu có sẵn trên chuỗi trong một phương tiện mà đảm bảo người dùng có thể truy cập và xác minh, để người dùng có thể tự tính toán trạng thái của rollup và tham gia làm người xác minh khi các người xác minh hiện tại ngoại tuyến. Dữ liệu có thể được nén một lần, nhưng không thể nén lại - - - nếu có thể, thì thường có một cách để đưa logic của bộ nén thứ hai vào bộ nén đầu tiên và đạt được lợi ích tương tự bằng cách nén một lần. Do đó, "rollups trên rollups" thực sự không thể cung cấp lợi ích lớn về khả năng mở rộng, nhưng như chúng ta sẽ thấy bên dưới, mô hình này có thể được sử dụng cho các mục đích khác.

Vậy phiên bản "hợp lý" của layer 3 là gì?

Chà, hãy xem những gì Starkware đề xuất trong bài viết của họ về layer 3s. Starkware được thành lập bởi những nhà mật mã học rất thông minh, họ rất lý trí, vì vậy nếu họ ủng hộ layer 3s, phiên bản của họ sẽ phức tạp hơn nhiều so với "nếu rollups nén dữ liệu 8 lần, thì rõ ràng rollups trên rollups sẽ nén dữ liệu 64 lần".

Đây là hình ảnh trong bài viết của Starkware:

Trích dẫn một vài câu:

Hình trên mô tả một ví dụ về hệ sinh thái này. L3 của nó bao gồm:

1. StarkNet với khả năng truy cập dữ liệu Validium, thường được sử dụng cho các ứng dụng cực kỳ nhạy cảm về giá.

2. Hệ thống StarkNet cụ thể cho ứng dụng được tùy chỉnh để có hiệu suất ứng dụng tốt hơn, chẳng hạn như thông qua việc áp dụng cấu trúc lưu trữ hoặc nén khả năng truy cập dữ liệu được chỉ định.

3. Hệ thống StarkEx (chẳng hạn như phục vụ cho dYdX, Sorare, Immutable và DeversiFi) có khả năng truy cập dữ liệu Validium hoặc Rollup, ngay lập tức mang lại lợi thế mở rộng đã được kiểm chứng cho StarkNet.

4. Các phiên bản StarkNet bảo vệ quyền riêng tư (trong ví dụ này cũng là L4) cho phép các loại giao dịch bảo vệ quyền riêng tư tồn tại mà không đưa chúng vào StarkNet công cộng.

Chúng ta có thể tóm tắt bài viết thành "Ba tầm nhìn cho 'L3s'":

• L2 được sử dụng cho khả năng mở rộng, L3 được sử dụng cho các chức năng tùy chỉnh, chẳng hạn như quyền riêng tư. Trong tầm nhìn này, không có nỗ lực nào để cung cấp "tăng trưởng khả năng mở rộng bình phương"; thay vào đó, có một lớp trong ngăn xếp có thể giúp ứng dụng mở rộng, sau đó có các lớp độc lập để đáp ứng nhu cầu chức năng tùy chỉnh cho các trường hợp sử dụng khác nhau.

• L2 được sử dụng cho khả năng mở rộng chung, L3 được sử dụng cho khả năng mở rộng tùy chỉnh. Khả năng mở rộng tùy chỉnh có thể có nhiều hình thức khác nhau: ứng dụng chuyên dụng sử dụng các thứ khác ngoài EVM để tính toán, rollups được tối ưu hóa cho định dạng dữ liệu của ứng dụng cụ thể (bao gồm việc tách "dữ liệu" và "bằng chứng" trong mỗi khối và thay thế bằng chứng bằng một SNARK duy nhất), v.v.

• L2 được sử dụng cho mở rộng không tin cậy (rollups), L3 được sử dụng cho mở rộng tin cậy yếu (validiums). Validium là hệ thống sử dụng SNARK để xác minh tính toán, nhưng để khả năng truy cập dữ liệu lại cho bên thứ ba đáng tin cậy hoặc ủy ban. Theo quan điểm của tôi, Validium bị đánh giá thấp nghiêm trọng: đặc biệt, nhiều ứng dụng "blockchain doanh nghiệp" thực sự có thể tốt nhất được phục vụ bởi những người xác minh chạy validium và định kỳ gửi băm đến máy chủ tập trung trên chuỗi để cung cấp dịch vụ tốt nhất. Mức độ an toàn của Validium thấp hơn rollups, nhưng có thể rẻ hơn nhiều.

Theo quan điểm của tôi, cả ba tầm nhìn này đều hợp lý. Ý tưởng về nén dữ liệu chuyên dụng cần một nền tảng riêng có thể là lập luận yếu nhất - - - việc thiết kế một giải pháp nén cơ sở chung cho L2 rất dễ dàng, người dùng có thể tự động mở rộng bằng cách sử dụng các bộ nén con cụ thể cho ứng dụng, nhưng ngoài điều đó, những trường hợp sử dụng này đều hợp lý. Nhưng điều này vẫn để lại một câu hỏi lớn: liệu kiến trúc ba lớp có phải là cách đúng để đạt được những mục tiêu này không? Việc neo các hệ thống xác minh, hệ thống bảo vệ quyền riêng tư và môi trường tùy chỉnh vào L2 thay vì chỉ đơn giản là neo vào L1 có ý nghĩa gì? Hóa ra, câu trả lời cho câu hỏi này khá phức tạp.

Trong cây con của L2, liệu việc gửi và rút tiền có trở nên rẻ hơn và dễ dàng hơn không?

Một lập luận có thể cho rằng mô hình ba lớp vượt trội hơn mô hình hai lớp là: mô hình ba lớp cho phép toàn bộ hệ sinh thái con tồn tại trong một rollup duy nhất, cho phép các hoạt động xuyên miền trong hệ sinh thái đó xảy ra rất rẻ mà không cần hoàn thành qua L1 đắt đỏ.

Nhưng thực tế cho thấy, ngay cả giữa hai L2 hoặc thậm chí L3, việc gửi và rút tiền cũng có thể rất rẻ. Chìa khóa ở đây là các token và tài sản khác không nhất thiết phải được phát hành trên chuỗi gốc. Nói cách khác, bạn có thể có token ERC20 trên Arbitrum, tạo ra một wrapper của nó trên Optimism, và di chuyển qua lại giữa hai bên mà không cần bất kỳ giao dịch L1 nào!

Hãy xem một hệ thống như vậy hoạt động như thế nào. Có hai hợp đồng thông minh: hợp đồng cơ sở trên Arbitrum và hợp đồng token được đóng gói trên Optimism. Để chuyển từ Arbitrum sang Optimism, bạn cần gửi token đến hợp đồng cơ sở, điều này sẽ tạo ra một biên nhận. Khi Arbitrum được xác nhận, bạn có thể lấy chứng minh Merkle của biên nhận đó và gắn nó vào trạng thái L1, sau đó gửi nó đến hợp đồng token được đóng gói trên Optimism, hợp đồng này sẽ xác minh và phát cho bạn một token được đóng gói. Để di chuyển token trở lại, bạn có thể thực hiện ngược lại cùng một thao tác.

Mặc dù việc chứng minh khoản gửi trên Arbitrum yêu cầu đường dẫn Merkle phải thông qua trạng thái L1, nhưng Optimism chỉ cần đọc gốc trạng thái L1 để xử lý khoản gửi - - - không cần giao dịch L1. Xin lưu ý rằng, do dữ liệu rollups là tài nguyên khan hiếm nhất, nên việc thực hiện thực tế của kế hoạch này sẽ sử dụng SNARK hoặc chứng minh KZG, thay vì sử dụng chứng minh Merkle trực tiếp, để tiết kiệm không gian.

Kế hoạch này có một điểm yếu chí mạng so với các token dựa trên L1 (ít nhất là trên optimistic rollups): khoản gửi cũng cần phải chờ cửa sổ chống gian lận. Nếu token được neo vào L1, việc rút từ Arbitrum hoặc Optimism về L1 cần một tuần trì hoãn, nhưng khoản gửi thì ngay lập tức. Tuy nhiên, trong kế hoạch này, cả khoản gửi và rút đều cần một tuần trì hoãn. Nói cách khác, vẫn chưa rõ liệu kiến trúc ba lớp trên rollups lý tưởng có tốt hơn không: để đảm bảo rằng các trò chơi chống gian lận xảy ra bên trong hệ thống tự chạy trên trò chơi chống gian lận là an toàn, có rất nhiều phức tạp kỹ thuật.

May mắn thay, những vấn đề này sẽ không trở thành vấn đề của ZK rollups. Vì lý do an toàn, ZK rollups không cần cửa sổ chờ kéo dài một tuần, nhưng vì hai lý do khác, chúng vẫn cần cửa sổ ngắn hơn (công nghệ thế hệ đầu tiên có thể cần 12 giờ). Đầu tiên, đặc biệt là các rollups ZK-EVM phức tạp hơn cần thời gian dài hơn để bao phủ thời gian tính toán không thể song song (non-parallelizable) của các khối. Thứ hai, vì lý do kinh tế, cần rất ít chứng minh được gửi để tối thiểu hóa chi phí cố định liên quan đến giao dịch chứng minh. Công nghệ ZK-EVM thế hệ tiếp theo bao gồm phần cứng chuyên dụng sẽ giải quyết vấn đề đầu tiên, trong khi kiến trúc xác minh theo lô tốt hơn có thể giải quyết vấn đề thứ hai. Chúng ta sẽ thảo luận về vấn đề tối ưu hóa và chứng minh theo lô tiếp theo.

Rollups và validiums có một sự đánh đổi giữa thời gian xác nhận và chi phí cố định. L3 có thể giúp giải quyết vấn đề này, nhưng còn gì khác có thể làm được điều này?

Chi phí của mỗi giao dịch rollups rất rẻ: nó chỉ là 16-60 byte dữ liệu, tùy thuộc vào ứng dụng. Nhưng rollups cũng phải trả chi phí cố định cao khi gửi một lô giao dịch lên chuỗi: optimistic rollups cần 21000 gas L1 cho mỗi lô, trong khi ZK rollups thì trên 400,000 gas (nếu bạn muốn chỉ sử dụng STARKS để cung cấp thứ gì đó an toàn với lượng tử, bạn sẽ cần hàng triệu gas).

Tất nhiên, rollup có thể đơn giản chọn đợi cho đến khi có giao dịch L2 trị giá 10 triệu gas để gửi toàn bộ lô (giao dịch), nhưng điều này sẽ khiến họ có khoảng thời gian giữa các lô rất dài, buộc người dùng phải chờ đợi lâu hơn để có xác nhận an toàn cao. Do đó, họ cần cân nhắc: khoảng thời gian giữa các lô dài hơn và chi phí tốt nhất, hoặc khoảng thời gian giữa các lô ngắn hơn và chi phí tăng lên đáng kể.

Để cho chúng ta một số con số cụ thể, hãy xem xét một ZK rollup có chi phí mỗi lô là 600,000 gas và xử lý mỗi giao dịch có chi phí 368 gas (23 byte). Giả sử rollups này đang ở giai đoạn đầu hoặc giữa giai đoạn áp dụng, với TPS là 5. Chúng ta có thể tính toán gas cho mỗi giao dịch với khoảng thời gian giữa các lô:

Nếu chúng ta bước vào một thế giới có nhiều xác minh tùy chỉnh và môi trường ứng dụng cụ thể, thì nhiều lượng xử lý mỗi giây sẽ thấp hơn 5TPS. Do đó, sự đánh đổi giữa thời gian xác nhận và chi phí bắt đầu trở nên rất quan trọng. Thực tế, mô hình "L3" thực sự giải quyết vấn đề này! ZK rollup trong ZK rollup, ngay cả là một triển khai đơn giản, cũng chỉ có khoảng 8,000 gas L1 chi phí cố định (500 byte cho chứng minh). Điều này sẽ thay đổi bảng trên thành:

Vấn đề cơ bản đã được giải quyết, vậy L3s có phải là tốt không? Có thể là vậy. Nhưng cần lưu ý rằng, có một cách khác để giải quyết vấn đề này đã được lấy cảm hứng từ ERC 4337 xác thực tổng hợp.

Chiến lược như sau. Ngày nay, nếu mỗi ZK rollup hoặc validium nhận được chứng minh, thì chứng minh S ~new~ = STF(S ~old~ ,D): gốc trạng thái mới phải là kết quả của việc xử lý đúng dữ liệu giao dịch hoặc gia tăng trạng thái trên gốc trạng thái cũ. Trong kế hoạch mới này, ZK rollup sẽ chấp nhận thông điệp từ hợp đồng xác thực theo lô, thông điệp này nói rằng nó đã xác minh chứng minh của một lô câu lệnh, trong đó mỗi câu lệnh có dạng S ~new~ = STF(S ~old~ ,D). Chứng minh theo lô này có thể được xây dựng thông qua các giải pháp SNARK đệ quy hoặc Halo tổng hợp.

Đây sẽ là một giao thức mở: bất kỳ ZK-rollup nào cũng có thể tham gia, và bất kỳ người xác thực theo lô nào cũng có thể tổng hợp chứng minh từ bất kỳ ZK-rollup tương thích nào và nhận được phí giao dịch từ tổng hợp. Hợp đồng xử lý sẽ xác minh một lần chứng minh, sau đó gửi một thông điệp đến mỗi rollups, kèm theo bộ ba (S ~old~ , S ~new~ , D) của rollups đó. Thực tế rằng bộ ba đến từ hợp đồng xử lý sẽ được sử dụng như bằng chứng để chứng minh rằng chuyển đổi là hợp lệ.

Nếu được tối ưu hóa đúng cách, chi phí cho mỗi lần tổng hợp trong kế hoạch này có thể gần 8000, trong đó 5000 dành cho việc thêm ghi trạng thái cập nhật mới, 1280 cho gốc cũ và gốc mới, và thêm 1720 cho việc xử lý dữ liệu khác. Do đó, nó sẽ mang lại cho chúng ta những tiết kiệm tương tự. Starkware thực sự đã có một thứ tương tự, gọi là SHARP, mặc dù nó (vẫn) không phải là một giao thức mở không cần cấp phép.

Một phản hồi cho phương pháp này có thể là: nhưng điều này thực sự không phải là một giải pháp lớp 3 khác sao? Chúng ta sẽ có lớp cơ sở \<- cơ chế theo lô \<- rollup hoặc validium thay thế cho lớp cơ sở \<- rollup \<- validium. Từ góc độ kiến trúc triết học nào đó, điều này có thể đúng. Nhưng có một sự khác biệt quan trọng: lớp trung gian không phải là một hệ thống EVM hoàn chỉnh phức tạp, mà là một đối tượng đơn giản hóa và chuyên biệt cao, do đó nó có khả năng an toàn hơn, có khả năng xây dựng mà không cần một token chuyên dụng khác, và có khả năng được quản lý ở mức tối thiểu và không thay đổi theo thời gian.

Kết luận: Thực sự "Layer" là gì?

Kiến trúc mở rộng ba lớp được tạo thành từ việc xếp chồng các giải pháp mở rộng giống nhau thường không hoạt động tốt. Hình thức rollups trên rollups (trong đó hai lớp rollups sử dụng cùng một công nghệ) cũng không đạt yêu cầu. Tuy nhiên, kiến trúc ba lớp với các mục đích khác nhau cho L2 và L3 có thể khả thi. Validiums trên rollups thực sự có ý nghĩa, ngay cả khi chúng không chắc chắn là cách tốt nhất để làm việc lâu dài.

Tuy nhiên, khi chúng ta bắt đầu đi sâu vào chi tiết nào kiến trúc có ý nghĩa, chúng ta sẽ đi vào các vấn đề triết học: cái gì là "lớp", cái gì không phải? Lớp cơ sở \<- cơ chế theo lô \<- rollup hoặc validium và lớp cơ sở \<- rollup \<- rollup hoặc validium đều thực hiện cùng một công việc, nhưng về cách thức hoạt động, lớp tổng hợp chứng minh trông giống như ERC-4337 hơn là rollups. Thông thường, chúng ta không gọi ERC-4337 là "layer 2". Tương tự, chúng ta không gọi Tornado Cash là "Layer 2", vì vậy nếu chúng ta muốn nhất quán, chúng ta sẽ không gọi hệ thống con tập trung vào quyền riêng tư nằm trên L2 là L3. Do đó, có một cuộc tranh luận ngữ nghĩa chưa được giải quyết về cái gì nên được gọi là "Layer" trước tiên.

Trong vấn đề này có nhiều trường phái tư tưởng có thể. Sở thích cá nhân của tôi là giới hạn thuật ngữ "Layer 2" cho những thứ có các thuộc tính sau:

1. Mục đích của chúng là để cải thiện khả năng mở rộng.

2. Chúng tuân theo mô hình "blockchain trong blockchain": chúng có cơ chế xử lý giao dịch riêng và trạng thái nội bộ của riêng chúng.

3. Chúng thừa hưởng toàn bộ tính bảo mật của chuỗi Ethereum.

Do đó, rollups lý tưởng và ZK rollups là L2, nhưng các giải pháp xác minh, tổng hợp chứng minh, ERC 4337, hệ thống bảo vệ quyền riêng tư trên chuỗi và Solidity là những thứ khác. Gọi một số trong số đó là L3 có thể có ý nghĩa, nhưng có thể không phải tất cả; dù sao đi nữa, bây giờ việc xác định định nghĩa có vẻ còn quá sớm, và kiến trúc của hệ sinh thái nhiều rollup còn xa mới ổn định, hầu hết các cuộc thảo luận chỉ diễn ra trên lý thuyết.

Nói cách khác, cuộc tranh luận ngôn ngữ không quan trọng bằng vấn đề kỹ thuật nào cấu trúc thực sự có ý nghĩa nhất. Rõ ràng, một số "layers" phục vụ cho các nhu cầu không mở rộng như quyền riêng tư có thể đóng một vai trò quan trọng, và cần phải lấp đầy chức năng quan trọng của tổng hợp chứng minh theo một cách nào đó, tốt nhất là thông qua các giao thức mở. Nhưng đồng thời, chúng ta có lý do kỹ thuật đầy đủ để giữ cho lớp trung gian liên kết môi trường người dùng và L1 đơn giản nhất có thể; trong nhiều trường hợp, "lớp dính" như một EVM tổng hợp có thể không phải là cách đúng đắn. Tôi đoán rằng, khi hệ sinh thái mở rộng L2 trưởng thành, các cấu trúc phức tạp (và đơn giản hơn) được mô tả trong bài viết này sẽ bắt đầu đóng vai trò lớn hơn.