Các dự án L2 sẽ ngày càng trở nên không đồng nhất.

  • Tiêu đề gốc: "Các loại lớp 2 khác nhau"

  • Tác giả gốc: Vitalik Buterin

  • Bản tổng hợp gốc: BlockBeats

Hệ sinh thái đã mở rộng nhanh chóng trong năm qua. Hệ sinh thái tổng hợp ZK-EVM, được đại diện theo truyền thống bởi StarkNet, Arbitrum, Optimism và Scroll, đã phát triển nhanh chóng để liên tục cải thiện tính bảo mật của nó và trang L2beat thực hiện rất tốt việc tóm tắt trạng thái của từng dự án.

Ngoài ra, chúng tôi cũng thấy rằng một số nhóm đang xây dựng chuỗi bên và cũng bắt đầu xây dựng các giải pháp tổng hợp (chẳng hạn như Polygon), một số dự án L1 đang cố gắng phát triển theo hướng xác minh tính hợp lệ (chẳng hạn như Celo), và cũng có những nỗ lực mới (như Linea, Zeth…).

Một trong những hậu quả không thể tránh khỏi của việc này là chúng tôi thấy các dự án L2 có xu hướng trở nên không đồng nhất hơn (tức là "đồng phân hóa"). Kết hợp với nhau Thuật ngữ này thường được sử dụng để mô tả các chuỗi khối, giao thức, công nghệ hoặc tài sản khác nhau có các đặc điểm, quy tắc hoặc thuộc tính khác nhau). Tôi kỳ vọng xu hướng này sẽ tiếp tục và đây là lý do:

  • Hiện tại, một số dự án L1 độc lập đang tìm cách tương tác chặt chẽ hơn với hệ sinh thái Ethereum và có khả năng chuyển đổi thành các dự án L2. Những dự án này có thể mong muốn áp dụng cách tiếp cận chuyển tiếp theo từng giai đoạn. Thực hiện chuyển đổi bán buôn ngay lập tức sẽ làm giảm tính khả dụng vì công nghệ chưa sẵn sàng để đưa mọi thứ vào kịch bản tổng hợp. Và trong một quá trình chuyển đổi tổng thể sau này, động lượng có thể bị hy sinh và quá muộn để có ý nghĩa thực tế.

  • Một số dự án tập trung muốn cung cấp bảo mật nhiều hơn cho người dùng của họ và đang khám phá các phương pháp tiếp cận dựa trên blockchain. Trong nhiều trường hợp, những dự án này trước đây có thể đã xem xét đến “chuỗi tập đoàn được cấp phép”. Trên thực tế, họ có thể chỉ cần đạt đến mức “bán tập trung”. Ngoài ra, chúng thường có thông lượng rất cao và không phù hợp với các kịch bản tổng hợp, ít nhất là trong thời gian ngắn.

  • Các ứng dụng phi tài chính, chẳng hạn như trò chơi hoặc mạng xã hội, muốn được phân cấp nhưng chỉ yêu cầu một mức độ bảo mật nhất định. Trong trường hợp của phương tiện truyền thông xã hội, nó thực sự liên quan đến việc xử lý các phần khác nhau của ứng dụng một cách khác nhau: các hoạt động hiếm và có giá trị cao như đăng ký tên người dùng và khôi phục tài khoản phải được thực hiện trong kịch bản tổng hợp, nhưng các hoạt động thường xuyên như bài đăng và cuộc thăm dò ý kiến ​​Và các hoạt động có giá trị thấp yêu cầu ít bảo mật hơn. Nếu blockchain bị lỗi và bài đăng của bạn biến mất, đó là một mức giá có thể chấp nhận được; nhưng nếu blockchain bị lỗi và bạn mất tài khoản thì đó là một mức giá lớn hơn nhiều.

Một chủ đề quan trọng là trong khi các ứng dụng và người dùng hiện đang sử dụng Ethereum L1 sẵn sàng trả phí cuộn nhỏ hơn nhưng vẫn có thể nhìn thấy được trong thời gian ngắn, thì người dùng từ thế giới không có blockchain lại ít sẵn sàng làm như vậy hơn: nếu trước đây bạn đã trả tiền nếu bạn đã trả tiền. 1 đô la trước đó, việc trả 0,10 đô la sẽ được chấp nhận nhiều hơn, trong khi nếu bạn trả 0 đô la trước đó thì việc trả 0,10 đô la sẽ ít được chấp nhận hơn. Điều này áp dụng cho các ứng dụng vẫn còn tập trung ngày nay, cũng như các dự án L1 nhỏ hơn thường có mức phí cực thấp mặc dù lượng người dùng nhỏ hơn.

Một câu hỏi tự nhiên là: Sự cân bằng phức tạp nào giữa các sơ đồ tổng hợp, tính hợp lệ và các hệ thống khác là hợp lý cho một ứng dụng nhất định?

Rollup vs Validiums vs Hệ thống bị ngắt kết nối

Khía cạnh đầu tiên về bảo mật và khả năng mở rộng mà chúng ta sẽ khám phá có thể được mô tả như sau: nếu bạn sở hữu một tài sản được phát hành trên L1, sau đó gửi nó vào L2, sau đó chuyển nó cho bạn, bạn sẽ nhận được bao nhiêu. có thể được lấy trở lại L1?

Ngoài ra 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 công nghệ đó là gì?

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

Điều đáng nói là đây là một kịch bản đơn giản hóa, trong đó 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ể thực hiện thanh toán trên chuỗi để trả phí giao dịch, lúc đó nhà điều hành sẽ buộc phải cung cấp một số thông tin cho chuỗi nếu không sẽ mất tiền đặt cọc.

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

Các tùy chọn trung gian này có thể được coi là nằm trong phạm vi giữa tổng hợp và xác thực. Nhưng điều gì thúc đẩy ứng dụng chọn một điểm cụ thể trên quang phổ đó, thay vì một số điểm xa hơn về bên trái hoặc bên phải? Ở đây, có hai yếu tố chính:

  1. Chi phí cung cấp dữ liệu gốc trên Ethereum sẽ giảm theo thời gian khi công nghệ phát triển. Hard fork tiếp theo của Ethereum, Dencun, đã giới thiệu EIP-4844 (hay còn gọi là “proto-danksharding”), cung cấp dữ liệu sẵn có trên chuỗi khoảng 32 kB/giây. Dự kiến, tính khả dụng của dữ liệu này sẽ tăng dần trong vài năm tới khi quá trình bảo vệ dữ liệu hoàn toàn được triển khai, với mục tiêu cuối cùng là mức độ sẵn có của dữ liệu khoảng 1,3 MB/giây. Đồng thời, những cải tiến về nén dữ liệu sẽ cho phép chúng tôi đạt được nhiều chức năng hơn với cùng một lượng dữ liệu.

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

Sự đánh đổi này đại khái trông như thế này:

Một loại khác đáng nói đến là xác nhận trước. Xác nhận trước là thông báo được ký bởi một nhóm người tham gia tổng hợp hoặc xác thực có nội dung "chúng tôi chứng minh các giao dịch này được bao gồm trong đơn đặt hàng này và gốc sau trạng thái là giao dịch này". Những người tham gia này có thể ký xác nhận trước không phù hợp với thực tế, nhưng nếu làm như vậy, tiền gửi của họ sẽ bị hủy. Điều này hữu ích cho các ứng dụng có giá trị thấp (chẳng hạn như thanh toán của người tiêu dùng), trong khi các ứng dụng có giá trị cao (chẳng hạn như chuyển khoản tài chính hàng triệu đô la) có thể chờ xác nhận "thường xuyên" được hỗ trợ bởi tính bảo mật hoàn toàn của hệ thống.

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

Đọc Ethereum mà không cần tin tưởng

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

Giả sử việc khôi phục xảy ra trên chuỗi khối Ethereum như trong hình. Đây có thể là sự cố ngừng hoạt động tạm thời trong một thời điểm khi chuỗi khối chưa được hoàn thiện hoặc có thể là khoảng thời gian rò rỉ không hoạt động khi chuỗi khối không được hoàn thiện trong một khoảng thời gian dài vì có quá nhiều trình xác thực ngoại tuyến.

Tình huống xấu nhất có thể xảy ra từ điều này như sau: Giả sử khối đầu tiên của chuỗi trên cùng đọc một số dữ liệu từ khối ngoài cùng bên trái của chuỗi Ethereum. Ví dụ: ai đó trên Ethereum gửi 100 ETH vào chuỗi hàng đầu. Sau đó Ethereum quay trở lại, tuy nhiên chuỗi trên cùng không quay trở lại. Kết quả là các khối trong tương lai trên chuỗi trên cùng tuân theo chính xác các khối trên chuỗi khối Ethereum mới, chính xác, nhưng giao dịch sai (tức là khoản tiền gửi 100 ETH) vẫn tồn tại trong chuỗi trên cùng. Một lỗ hổng như vậy có thể dẫn đến việc phát hành thêm tiền tệ, biến ETH bắc cầu trên chuỗi hàng đầu 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ó thể đọc các khối đã được Ethereum hoàn thiện, do đó nó không bao giờ cần phải khôi phục;

2. Nếu Ethereum quay trở lại, chuỗi trên cùng cũng có thể quay trở lại. Cả hai đều có thể ngăn chặn vấn đề này. Cách thứ nhất dễ thực hiện hơn nhưng có thể dẫn đến mất chức năng trong một thời gian dài nếu Ethereum bước vào giai đoạn rò rỉ không hoạt động. Cách thứ hai khó thực hiện hơn nhưng luôn đảm bảo chức năng tối ưu.

Lưu ý rằng cách tiếp cận đầu tiên có trường hợp đặc biệt. Nếu một cuộc tấn công 51% xảy ra trên Ethereum, khiến hai khối mới không tương thích xuất hiện cùng lúc, cả hai khối dường như đã hoàn tất, thì chuỗi trên cùng có thể chọn sai khối (tức là một vùng cuối cùng không được Ethereum hỗ trợ). khối đồng thuận xã hội)) và cần phải khôi phục để chuyển sang khối chính xác. Có thể cho rằng, không cần thiết phải viết mã trước để xử lý tình huống này; vấn đề này có thể được giải quyết bằng cách hard fork chuỗi trên cùng.

Có hai lý do quan trọng giải thích cho khả năng đọc Ethereum mà không cần sự tin cậy của blockchain:

Đầu tiên, khả năng này có thể làm giảm những lo ngại về bảo mật liên quan đến việc kết nối các token được phát hành trên Ethereum (hoặc các giải pháp lớp thứ hai khác) với chuỗi đó;

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

Mặc dù còn nhiều tranh cãi nhưng tầm quan trọng của cách tiếp cận đầu tiên đã được công nhận rộng rãi. Một lần nữa, cách tiếp cận thứ hai rất quan trọng vì nó có nghĩa là bạn có thể có một chiếc 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.

Việc sở hữu một cây cầu có làm cho nó có giá trị không?

Giả sử chuỗi hàng đầu ban đầu được ra mắt dưới dạng chuỗi độc lập và sau đó ai đó đã triển khai 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 các tiêu đề khối từ chuỗi trên cùng, xác minh rằng bất kỳ tiêu đề khối nào được gửi tới nó đều kèm theo chứng chỉ hợp lệ chứng minh rằng tiêu đề khối đã được chấp nhận bởi sự đồng thuận của chuỗi trên cùng và thêm khối tiêu đề vào danh sách.

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

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

1. Chúng tôi đang xác minh chữ ký của khối, nhưng không xác minh liệu quá trình chuyển đổi trạng thái có chính xác hay không. Vì vậy, nếu bạn gửi tài sản được phát hành trên Ethereum vào chuỗi trên cùng và người xác thực của chuỗi trên cùng trở nên không trung thực, họ có thể ký chuyển đổi trạng thái không hợp lệ và do đó đánh cắp những tài sản đó;

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

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

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

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

1. Đặt hợp đồng cầu nối vào chuỗi trên cùng để xác minh khối Ethereum đã hoàn tất;

2. Bao gồm hàm băm của khối Ethereum gần đây nhất trong mỗi khối của chuỗi trên cùng và sử dụng quy tắc lựa chọn phân nhánh để buộc chuỗi băm. Nói cách khác, khối chuỗi trên cùng sẽ được liên kết với khối Ethereum trên chuỗi không chính thì bản thân nó không phải là chuỗi chính. Nếu khối chuỗi trên cùng liên kết với khối Ethereum ban đầu nằm trên chuỗi chính nhưng sau đó trở thành chuỗi không chính, khối chuỗi trên cùng cũng phải trở thành chuỗi không chính.

Các liên kết màu tím này có thể là liên kết băm hoặc hợp đồng cầu nối để xác minh sự đồng thuận của Ethereum.

Như thế này đủ chưa? Thực ra là chưa đủ, vì có một số trường hợp Edge nhỏ:

  1. Điều gì sẽ xảy ra nếu Ethereum bị tấn công 51%?

  2. Làm cách nào để xử lý việc nâng cấp hard fork Ethereum?

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

Một cuộc tấn công 51% vào Ethereum sẽ dẫn đến hậu quả tương tự như một cuộc tấn công 51% vào chuỗi hàng đầu, nhưng ngược lại. Một hard fork của Ethereum có thể vô hiệu hóa cầu nối Ethereum trong chuỗi trên cùng. Một cam kết xã hội, nghĩa là nếu Ethereum khôi phục một khối cuối cùng, nó sẽ khôi phục khối đó. Nếu Ethereum thực hiện một hard fork, nó sẽ thực hiện một hard fork. Đây là cách rõ ràng nhất để giải quyết vấn đề này.

Một lời hứa như vậy có thể không bao giờ thực sự cần phải được thực hiện: nếu cơ quan quản trị của chuỗi trên cùng phát hiện ra bằng chứng cho thấy một cuộc tấn công hoặc hard fork có thể đã xảy ra, cơ quan quản trị có thể được kích hoạt và chuỗi trên cùng sẽ chỉ được phân nhánh cứng nếu quản trị cơ thể thất bại.

Câu trả lời khả thi duy nhất cho câu hỏi thứ ba là có một số hình thức quản trị trên Ethereum để làm cho hợp đồng cầu nối trên Ethereum nhận thức được việc nâng cấp hard fork lên chuỗi trên cùng.

Tóm tắt: Cầu nối xác minh hai chiều gần như đủ để tạo ra tính hợp lệ của blockchain. Yếu tố chính còn lại là một cam kết xã hội rằng nếu có điều gì đó bất thường xảy ra với Ethereum khiến hợp đồng cầu nối hoạt động bình thường thì chuỗi khối khác sẽ phản hồi bằng một hard fork.

Tóm lại là

"Kết nối với Ethereum" có hai khía cạnh chính:

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

  2. Đọc tính bảo mật của Ethereum.

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

Lưu ý rằng mỗi chiều được đo theo hai cách khác nhau (thực tế có bốn chiều): Bảo mật khai thác có thể được đo bằng (i) mức độ bảo mật 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 bảo mật cao nhất;

Và bảo mật đọc có thể được đo bằng (i) tốc độ liên kết có thể đọc các khối của Ethereum, đặc biệt là sự khác biệt giữa khối cuối cùng và bất kỳ khối nào và (ii) tốc độ liên kết xử lý những thứ như tấn công 51% và được đo theo mức độ về cam kết xã hội trong các tình huống khó khăn như hard fork.

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

Liên kết gốc

Bài viết này được in lại với sự cho phép của BlockBeats

Bài viết này, người sáng lập Ethereum Vitalik Buterin phân loại sự khác biệt giữa các loại Lớp 2 khác nhau, lần đầu tiên xuất hiện trên Zombit.