Tác giả gốc: jolestar (X: @jolestar)
Tôi thấy một số người bạn nói về Dựa Rollup, chủ yếu là từ góc độ bảo mật. Tôi muốn nói về quan điểm của tôi về Dựa Booster Rollup từ góc độ mối quan hệ giữa L1 và L2 và việc xây dựng các ứng dụng.
Ý tưởng của Dựa trên Rollup thực sự rất đơn giản, tức là người dùng gửi trực tiếp các giao dịch L2 đến L1, L1 sắp xếp và đóng gói chúng. Tuy nhiên, L1 không xác minh tính hợp lệ của các giao dịch mà chỉ đảm bảo thứ tự và tính sẵn có của chúng. các giao dịch, trong khi L2 là người thực thi thuần túy. Thực thi các giao dịch L2 được đóng gói trên L1. Bạn có thấy điều này quen thuộc không? Đây không phải là chế độ Ghi chú sao? Đúng, Người lập chỉ mục của dòng chữ ở đây có thể hiểu là L2. Tôi đã nói điều này trong bài viết của mình (Dòng chữ là lỗi hay tính năng).
Booster Rollup bắt đầu từ một góc nhìn khác Làm cách nào để đọc trực tiếp trạng thái của L1 thông qua hợp đồng trên L2? Ý tưởng thực sự không phức tạp vì Dựa Rollup đã thực hiện giao dịch L2 trên L1, vậy còn việc thực hiện giao dịch L1 thì sao? Bằng cách này, các trạng thái của L1 và L2 nằm trong một cây trạng thái lớn và hợp đồng của L2 có thể đọc trực tiếp trạng thái của L1.
Vì vậy, cũng có những dự án kết hợp Based Rollup và Booster Rollup, gọi là Based Booster Rollup (BBR), chẳng hạn như taiko.
Nền BBR
BBR đã thu hút sự chú ý của thị trường kể từ khi nó được đề xuất. Bối cảnh chính là vấn đề phân mảnh gây ra bởi giải pháp L2 chính thống hiện tại của Ethereum, sự phân mảnh giữa L1 và L2 và sự phân mảnh giữa L2. Các chức năng được cung cấp bởi giải pháp L2 hiện tại không khác nhiều so với Alt-L1, cả từ góc độ của nhà phát triển và người dùng, việc đọc dữ liệu L1 vẫn dựa vào Oracle, tài sản vẫn cần được bắc cầu và ví phải chuyển đổi mạng. Sự tách biệt này cũng dẫn đến một vấn đề khác. Sự ràng buộc giữa L1 và L2 không chặt chẽ có thể thêm cơ chế đồng thuận bất cứ lúc nào để trở thành Alt-L1, “tự lực như vua”, đồng thời cho phép các nhà phát triển và Người dùng. về cơ bản là thờ ơ. Mối quan hệ ràng buộc chính hiện tại xuất phát từ ràng buộc của EF về tính hợp pháp: L2 phải coi L1 là DA, nhưng rõ ràng ràng buộc này không mạnh.
Vậy nếu tất cả giải pháp L2 hiện tại được thay thế bằng giải pháp Based Rollup thì vấn đề có được giải quyết không? Tôi đoán Chủ nghĩa lạc quan và Trọng tài sẽ nhảy ra và nói, việc chuyển sang Dựa trên Rollup có dễ dàng không? Giờ đây, các giải pháp L2 chính đều có cơ chế Force Inclusion L2 trực tiếp loại bỏ Sequencer và cho phép người dùng gửi các giao dịch đến L1 thông qua Force Inclusion. Nó không nhận ra Dựa trên Rollup sao?
Nhưng liệu điều này có thể giải quyết được vấn đề phân mảnh? không thể. Mặc dù Arb và Op đều gửi các giao dịch tới L1 theo thời gian thực và các gói L1 và sắp xếp chúng, nhưng chúng vẫn tách biệt vì mỗi gói chỉ nhận ra các giao dịch của riêng mình. Tại thời điểm này, mọi người nên hiểu rằng chìa khóa để giải quyết vấn đề phân mảnh trong Dựa Rollup là có các giao dịch hoặc dữ liệu có thể được chia sẻ giữa L2 và định dạng dữ liệu này yêu cầu:
Nó phải là định dạng độc lập với nền tảng và việc triển khai được xác định trên L1. Các tài khoản L2 khác nhau có các máy ảo khác nhau và các giao dịch tương ứng của chúng không thể được chia sẻ trực tiếp.
Nó đòi hỏi sự đồng thuận giữa các L2, được hỗ trợ bởi nhiều L2.
Do đó, trước tiên nó phải là giao thức và giao thức công khai và định dạng dữ liệu phải được thiết kế trước. Chỉ dữ liệu cần thiết cho giao thức mới được lưu trữ trên chuỗi. Việc thực thi và xác minh là các giải pháp hỗ trợ ngoài chuỗi. Nhưng thực sự khá khó để đạt được hai điểm này. Trước hết, các nhà phát triển trong hệ sinh thái Ethereum thường thiết kế giao thức thông qua hợp đồng thông minh và không có thói quen thiết kế giao thức trực tiếp dựa trên định dạng dữ liệu. Nỗ lực chính theo hướng này là Ethscriptions khi các dòng chữ còn rất hot thời gian qua. Điểm thứ hai khó hơn và cần phải thực hành cũng như thời gian để xác minh.
Từ BBR đến BBSR, L2 có thể xếp chồng
Sau khi nói về vấn đề chia sẻ dữ liệu, hãy nói đến vấn đề trải nghiệm người dùng. Rõ ràng, nếu tất cả các giao dịch được người dùng gửi trực tiếp đến L1, trải nghiệm sẽ gần giống như sử dụng L1, cho dù đó là gas hay thời gian xác nhận. Vì vậy, một số người bắt đầu thiết kế giao thức xác nhận trước dựa trên tổng hợp. Nhưng nếu giao thức xác nhận trước thực sự có thể hoạt động, thì tất cả các giao dịch trước tiên phải trải qua giao thức xác nhận trước, chẳng phải đó là một Trình sắp xếp chuỗi sao? Nói chuyện này có lãng phí thời gian không?
Nguyên nhân của sự mâu thuẫn này là do mọi người nhầm lẫn một số loại giao dịch:
Các giao dịch được người dùng gửi trực tiếp tới L1 và được L1 thực hiện và xác minh được gọi là giao dịch L1.
Người dùng gửi trực tiếp đến L1, nhưng L1 không trực tiếp xác minh và thực hiện giao dịch dữ liệu của giao thức dùng chung giữa L2, có thể gọi là giao dịch L1.5.
Người dùng gửi giao dịch trực tiếp đến Bộ sắp xếp L2 và Bộ sắp xếp thứ tự xác nhận trước và thực hiện giao dịch, đây là giao dịch dành riêng cho L2.
Dựa trên Rollup chỉ liên quan đến 1 và 2. 3 là phương pháp làm việc hiện tại của Sequencer Rollup. Cả hai có thể được kết hợp.
Giả sử có một giải pháp Rollup như vậy:
Trình sắp xếp tự động đồng bộ hóa tất cả các giao dịch L1 (bao gồm L1.5) và thực hiện chúng theo thứ tự do L1 đưa ra.
Trình sắp xếp chuỗi nhận các giao dịch L2 cùng lúc, sắp xếp chúng cùng với các giao dịch L1 và thực hiện chúng.
Thông qua 1, nó triển khai Dựa và Booster, và đến 2, nó đạt được sự xác nhận nhanh chóng về các giao dịch L2 mà không làm mất trải nghiệm người dùng. Nếu bạn làm theo cách đặt tên trước đó thì nên gọi là BBSR (Based Booster Sequencer Rollup), tuy nhiên nó hơi dài và không dễ hiểu nên mình gọi là Stackable L2, stackable L2 Như tên gợi ý, L2 được xếp chồng lên nhau. trên L1 và L2 chứa Tất cả các giao dịch và trạng thái của L1. Đây là giải pháp của @RoochNetwork.
Làm thế nào để đảm bảo DA của giao dịch L2? Rollup hoặc triển khai?
Nếu giải pháp trên được áp dụng, sẽ hơi lạ khi L2 đóng gói giao dịch của chính mình và gửi lại cho L1, vì L2 sẽ đọc giao dịch L1 đã đóng gói giao dịch của chính nó và thực hiện lại nó. đầu ra của chính nó cũng trở thành đầu vào của chính nó. Vì vậy giải pháp của Rooch là Rollout thay vì Rollup. Bởi vì không gian khối L1 rất quý giá về lâu dài nên nhiều giao dịch L2 chiếm giữ không gian L1 là mô hình "involution" nên được dành riêng cho các giao dịch L1 và L1.5 và nên theo đuổi các giao dịch cấp ứng dụng L2 Không gian khối rẻ hơn. và mở rộng không gian khối mới thông qua "gia công phần mềm" cũng sẽ có lợi cho sự phát triển của toàn bộ hệ sinh thái ngành.
BBSR/Thực hành L2 có thể xếp chồng của Hệ sinh thái Bitcoin
Các mô tả trước đây đều dựa trên quan điểm của Ethereum và Rooch là triển khai BBSR hoặc L2 có thể xếp chồng đầu tiên của Bitcoin. Hãy nói về sự khác biệt về sinh thái của Bitcoin.
Không có hợp đồng thông minh hoàn chỉnh Turing trên Bitcoin L2 và chế độ Dựa trên Rollup thực sự trở thành một lợi thế. Vì Dựa Rollup không yêu cầu L1 thực hiện và xác minh giao dịch nên nó chỉ cần đảm bảo Permission Less và DA. Điều này cũng buộc các dự án trong hệ sinh thái Bitcoin phải bắt đầu thiết kế các giao thức dựa trên cấu trúc dữ liệu từ rất lâu trước đây. Cho dù đó là đồng tiền màu hay sau này là RGB, Taproot Assets, Ordinals Inscription, Atomics, Runs, v.v., tất cả đều là nỗ lực. trong danh mục này có thể được bao gồm trong khái niệm chung về giao thức CSV (Xác thực phía máy khách) và các giao dịch của chúng đều là các giao dịch L1.5 điển hình. Nếu một dự án trong hệ sinh thái Ethereum muốn triển khai Dựa L2 và thiết kế một giao thức được chia sẻ giữa nhiều L2 thì nhìn chung nó sẽ tương tự như giao thức trên.
Hãy lấy Rooch làm ví dụ để giải thích chế độ hoạt động của BBSR trên Bitcoin:
Người dùng sẽ gửi trực tiếp các giao dịch L1 và L1.5 tới Bitcoin vì giao thức này là công khai nên điểm vào có thể là bất kỳ ứng dụng nào.
Rooch sẽ đồng bộ hóa tất cả các giao dịch L1, xử lý UTXO trong đó và tìm hiểu xem nó có mang thông tin giao thức bổ sung hay không, sau đó sử dụng mô-đun Move tương ứng để xử lý nó. Ví dụ: các giao dịch được xác định là Dòng chữ sẽ được xử lý bởi mô-đun ord, trong khi các giao dịch của Babylon Stake sẽ được xử lý bởi mô-đun bbn.
Người dùng gửi trực tiếp các giao dịch L2 đến nút Sequencer của Rooch để xử lý. Kết quả thực hiện của ba giao dịch trên sẽ tạo ra một cây trạng thái hoàn chỉnh và hợp đồng ứng dụng có thể tận dụng tối đa các trạng thái do giao dịch L1 và L1.5 tạo ra.
Các ứng dụng ở chế độ này có thể thiết kế hai giao dịch, một là giao dịch giao thức công khai (Phần dựa trên, trên L1) và giao dịch còn lại là giao dịch ứng dụng (được sắp xếp theo Sequencer. Cả hai có thể hợp tác với nhau thông qua chế độ Booster để đảm bảo Ít quyền hơn). đồng thời đảm bảo trải nghiệm người dùng.
Như đã đề cập trước đó, việc thiết kế các giao thức công khai đòi hỏi thời gian và thực hành để xác minh và đạt được sự đồng thuận. Điều mà Rooch có thể cung cấp là một môi trường thử nghiệm thuận tiện: nếu bạn muốn thiết kế một ứng dụng hoặc giao thức tài sản mới trên Bitcoin, bạn chỉ cần xác định After. xác định định dạng giao thức và triển khai mô-đun hợp đồng Move tương ứng để xử lý nó, bạn có thể thử nghiệm bằng cách xây dựng các kịch bản ứng dụng.
Tất nhiên, hệ sinh thái Bitcoin cũng có một số thách thức trên lộ trình này:
Thiết kế ban đầu của Bitcoin không có đủ chỗ để mở rộng cho kịch bản DA này, do đó, hình thức dữ liệu được ghi vào Bitcoin là một trong những hướng mà nhiều giao thức trước đó đã cố gắng khám phá, chẳng hạn như nhúng dữ liệu OP_RETURN, thông qua Witness, và ngay cả với chữ ký, hiện tại vẫn thiếu các giải pháp tiêu chuẩn hóa.
Hệ sinh thái Bitcoin chưa đạt được sự đồng thuận rộng rãi về giá trị của dữ liệu được nhúng trong chuỗi. Đây cũng là hướng đi mà tôi đã kêu gọi kể từ lần đăng cuối cùng. Hệ sinh thái Bitcoin nên chú ý đến Bitcoin như một tuyến dữ liệu công cộng toàn cầu (. giá trị Bus dữ liệu).
Giá trị của L1 như một bus dữ liệu công cộng toàn cầu
Kể từ mùa hè DeFi, toàn bộ lĩnh vực Tiền điện tử đã khám phá các ứng dụng mới bên ngoài DeFi. Cho dù đó là cơn sốt ghi chú của Bitcoin hay cuộc thảo luận Dựa trên Rollup gần đây, nó có thể được hiểu là sự khám phá lại giá trị của L1 dưới dạng bus dữ liệu. Từ góc độ của các hệ thống phân tán, việc tách rời giữa các hệ thống có thể đạt được thông qua bus dữ liệu và việc tách rời giữa các hệ thống là một trong những điều kiện tiên quyết chính để đạt được Quyền ít hơn. Ví dụ: sàn giao dịch phi tập trung trong hệ sinh thái Crypto tận dụng tối đa bus dữ liệu của chuỗi khối để đạt được việc kết nối "phi tập trung", điều này khó đạt được trực tiếp trong hệ thống tài chính truyền thống. Nếu muốn hỗ trợ các ứng dụng phức tạp hơn, bạn chỉ cần nâng cấp các giao dịch chuyển đơn giản lên các giao dịch giao thức ứng dụng để đạt được ít Quyền hơn ở cấp ứng dụng, ít xâm phạm nhất vào các ứng dụng hiện có.
Bài viết này chủ yếu thảo luận về BBR từ góc độ sinh thái và ứng dụng. Tính bảo mật của chế độ BBR và khả năng tương tác của các trạng thái L1, L1.5 và L2 trong chế độ BBR sẽ được thảo luận chi tiết trong các bài viết sau. Đính kèm bên dưới là một số liên kết có liên quan, bao gồm các bài viết lịch sử của tôi và lời giải thích của một số nhà bình luận về Dựa trên Tổng hợp từ các góc độ khác nhau.
Các liên kết liên quan: 1. Stackable L2 — một giải pháp mở rộng blockchain mới https://rooch.network/zh-CN/blog/stackable-l2
2. Nên làm gì với Lớp 2 của Bitcoin? https://x.com/jolestar/status/1717358817992995120 Tôi đã thiết kế kế hoạch ban đầu từ cách L2 sử dụng trạng thái và dữ liệu trên Bitcoin L1. Trong phần bình luận, một người bạn đã đề cập đến kế hoạch Booster và cuối cùng kế hoạch Booster đã được áp dụng trong thực tế. .
3. Dòng chữ này là lỗi hay tính năng? https://x.com/jolestar/status/1732711942563959185Giải thích giá trị của chữ khắc từ góc độ cách L2 được xây dựng, bao gồm cả vấn đề tương thích khuyến khích của L1 và L2.
4. Thảo luận dựa trên lý thuyết trừ Dựa Rollup @kerne l1 983 https://web3 caff.com/zh/archives/108241
5. Bài viết của @jason_chen 998 về Dựa trên bản tổng hợp https://x.com/jason_chen998/status/1799692331635048697
6. Báo cáo nghiên cứu theo dõi tổng hợp dựa trên https://research.web3 caff.com/zh/archives/22719
Liên kết gốc
