Phân tích chuyên sâu về Based Booster Rollup: bối cảnh, thực tiễn và triển vọng

Tác giả gốc: jolestar (X: @jolestar )

Tôi thấy một số bạn nói về Based Rollup, hầu hết đều nói về nó theo góc độ bảo mật. Tôi muốn nói về quan điểm của tôi về Based Booster Rollup theo 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 Based Rollup thực ra rất đơn giản, tức là người dùng trực tiếp gửi các giao dịch L2 đến L1, được sắp xếp và đóng gói bởi L1. 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 khả dụng của các giao dịch. L2 là một trình 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 quen không? Đây không phải là chế độ Inscription sao? Đúng vậy, Indexer của inscription có thể được hiểu là L2 ở đây. Tôi đã nói điều này trong bài viết Inscription là một lỗi hay một tính năng?

Booster Rollup bắt đầu từ một góc nhìn khác. Làm thế 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 không phức tạp. Vì Based Rollup đã thực hiện các giao dịch L2 trên L1, tại sao không thực hiện cả các giao dịch L1? Theo 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 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, được gọi là Based Booster Rollup (BBR), chẳng hạn như taiko.

Bối cảnh của BBR

Từ thời điểm BBR được đề xuất cho đến khi nó thu hút được sự chú ý của thị trường, bối cảnh chính là vấn đề chia tách do giải pháp L2 chính thống hiện tại của Ethereum gây ra, sự chia tách giữa L1 và L2 và sự chia tách giữa L2. Các chức năng do giải pháp L2 hiện tại cung cấp, cho dù từ góc nhìn của nhà phát triển hay góc nhìn của người dùng, đều không khác nhiều so với Alt-L1. Việc đọc dữ liệu L1 vẫn phụ thuộc vào Oracle, tài sản vẫn cần một cầu nối và ví phải chuyển đổi mạng. Sự chia tách này cũng gây ra một vấn đề khác. Sự ràng buộc giữa L1 và L2 không chặt chẽ như vậy. L2 có thể thêm một bộ cơ chế đồng thuận bất kỳ lúc nào để trở thành Alt-L1, tự đứng vững và về cơ bản khiến các nhà phát triển và người dùng không biết gì. Mối quan hệ ràng buộc chính hiện tại xuất phát từ các ràng buộc của EF đối với tính chính thống: L2 phải sử dụng L1 làm DA, nhưng rõ ràng ràng buộc này không đáng tin cậy.

Vậy nếu chúng ta thay thế tất cả các giải pháp L2 hiện tại bằng các giải pháp Based Rollup, liệu vấn đề có được giải quyết không? Tôi đoán Optimism và Arbitrum sẽ nhảy ra và nói, chuyển sang Based Rollup có dễ không? Các giải pháp L2 chính hiện có cơ chế Force Inclusion. L2 trực tiếp xóa Sequencer và cho phép người dùng gửi giao dịch đến L1 thông qua Force Inclusion. Based Rollup không được triển khai sao?

Nhưng liệu điều này có thể giải quyết được vấn đề phân mảnh không? Không. Mặc dù Arb và Op đều gửi giao dịch đến L1 theo thời gian thực và L1 đóng gói và sắp xếp chúng, chúng vẫn bị phân mảnh vì mỗi giao dịch chỉ nhận ra 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 cho Based 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à một định dạng bất chấpđược thực hiện trên L1 độc lập với nền tảng và triển khai. Các tài khoản L2 và máy ảo khác nhau là khác nhau và các giao dịch 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 và sự hỗ trợ từ nhiều L2.

Do đó, trước tiên phải là một giao thức, trước tiên là thiết kế một giao thức công khai và định dạng dữ liệu, chỉ lưu trữ dữ liệu mà giao thức yêu cầu trên chuỗi, thực thi và xác minh ngoài chuỗi và triển khai các giải pháp hỗ trợ cho các L2 khác nhau. Nhưng thực tế 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ế các giao thức thông qua hợp đồng thông minh và không có thói quen thiết kế các giao thức trực tiếp dựa trên các định dạng dữ liệu. Nỗ lực chính theo hướng này là Ethscriptions khi các bản ghi phổ biến lần trước. Điểm thứ hai thậm chí còn khó hơn và đòi hỏi phải thực hành và thời gian để xác minh.

Từ BBR đến BBSR, có thể xếp chồng L2

Sau khi nói về vấn đề chia sẻ dữ liệu, chúng ta hãy nói về trải nghiệm của người dùng. Rõ ràng là nếu tất cả các giao dịch được người dùng gửi trực tiếp đến L1, thì trải nghiệm gần như giống hệt như khi sử dụng L1, bất kể là Gas hay thời gian xác nhận. Vì vậy, một số người bắt đầu thiết kế một giao thức xác nhận trước cho Based Rollup, 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 cần phải vượt qua giao thức xác nhận trước trước, vậy thì đó không phải là Sequencer sao? Nói về điều này có phải là lãng phí thời gian không?

Mâu thuẫn này phát sinh do mọi người nhầm lẫn giữa một số loại giao dịch:

1. Các giao dịch do người dùng gửi trực tiếp đến L1 và được L1 thực hiện và xác minh là giao dịch L1.

2. 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 chia sẻ giữa L2 có thể được gọi là giao dịch L1.5.

3. Người dùng trực tiếp gửi giao dịch đến L2 Sequencer, giao dịch này sẽ được xác nhận trước và thực hiện bởi Sequencer, một giao dịch chuyên dụng của một L2 nhất định.

Based 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ể kết hợp.

Giả sử có một giải pháp Rollup như sau:

1. Sequencer 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 chỉ định.

2. Bộ sắp xếp tiếp 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 Based và Booster, và thông qua 2, nó nhận ra xác nhận nhanh các giao dịch L2 mà không ảnh hưởng đến trải nghiệm của người dùng. Theo sơ đồ đặt tên trước đó, nó sẽ được gọi là BBSR (Based Booster Sequencer Rollup), nhưng nó hơi dài và không dễ hiểu, vì vậy tôi gọi nó là Stackable L2. Như tên gọi của nó, L2 được xếp chồng lê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 @RoochMạng .

Làm thế nào để đảm bảo DA của các giao dịch L2? Rollup hay Rollout?

Nếu giải pháp trên được áp dụng, sẽ hơi lạ khi L2 đóng gói các giao dịch của riêng mình và gửi lại cho L1, vì L2 sẽ đọc các giao dịch L1 đóng gói các giao dịch của riêng mình và thực hiện lại chúng, điều này hơi giống với đầu ra của chính nó cũng trở thành đầu vào của chính nó. Do đó, giải pháp của Rooch là Rollout thay vì Rollup. Bởi vì về lâu dài, không gian khối của L1 rất quý giá và nhiều giao dịch L2 chiếm không gian của L1 là chế độ lăn. Không gian L1 nên được dành cho các giao dịch L1 và L1.5. Các giao dịch cấp ứng dụng L2 nên tìm kiếm không gian khối rẻ hơn và mở rộng không gian khối mới thông qua việc lăn ra, điều này cũng có lợi cho sự phát triển của toàn bộ hệ sinh thái ngành.

Thực hành BBSR/Stackable L2 trong hệ sinh thái Bitcoin

Các mô tả trước đây đều theo góc nhìn của Ethereum. Vì Rooch là BBSR hoặc Stackable L2 đầu tiên của Bitcoin, chúng ta hãy nói về sự khác biệt trong hệ sinh thái Bitcoin.

Không có hợp đồng thông minh Turing-complete trên Bitcoin L2, điều này trở thành một lợi thế trong chế độ Based Rollup. Vì Based Rollup không cần L1 để thực thi và xác minh giao dịch, 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 thiết kế các giao thức dựa trên các cấu trúc dữ liệu từ rất lâu trước đây. Cho dù đó là tiền xu có màu hay sau này là RGB, Taproot Assets, Ordinals Inscription, Atomicals, Runs, v.v., tất cả đều là những nỗ lực trong danh mục này và có thể được đưa vào khái niệm rộng về giao thức CSV (Xác thực phía máy khách). Các giao dịch của chúng là các giao dịch L1.5 điển hình. Nếu các dự án trong hệ sinh thái Ethereum muốn thực hành Based L2 và thiết kế một giao thức được chia sẻ giữa nhiều L2, thì nó sẽ gần giống với 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:

1. Người dùng sẽ trực tiếp gửi giao dịch L1 và L1.5 đến Bitcoin. Vì giao thức là công khai nên điểm vào có thể là bất kỳ ứng dụng nào.

2. 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 có thông tin giao thức bổ sung nào không, sau đó sử dụng mô-đun Move tương ứng để xử lý. Ví dụ, các giao dịch được xác định là Inscription sẽ được xử lý bởi mô-đun ord, trong khi các giao dịch Babylon Staking sẽ được xử lý bởi mô-đun bbn.

3. Người dùng trực tiếp gửi giao dịch L2 đến nút Roochs Sequencer để 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 đầy đủ các trạng thái do giao dịch L1 và L1.5 tạo ra.

Các ứng dụng trong chế độ này có thể thiết kế hai loại 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à loại còn lại là giao dịch ứng dụng (được sắp xếp theo trình tự của Sequencer). Hai loại này có thể hợp tác với nhau thông qua chế độ Booster để đảm bảo Permission Less đồng thời đảm bảo trải nghiệm của 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, và Rooch có thể cung cấp một môi trường thử nghiệm thuận tiện như vậy: 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 định dạng giao thức, sau đó triển khai mô-đun hợp đồng Move tương ứng để xử lý, sau đó 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 phải đối mặt với một số thách thức trên con đường này:

1. Khi Bitcoin được thiết kế lần đầu, nó không để lại đủ chỗ để mở rộng cho kịch bản DA này. Do đó, cách ghi dữ liệu vào Bitcoin là một trong những hướng mà nhiều giao thức khác nhau đã cố gắng khám phá, chẳng hạn như nhúng dữ liệu vào OP_RETURN, thông qua Witness và thậm chí thông qua chữ ký. Hiện tại, vẫn còn thiếu các giải pháp chuẩn hóa.

2. 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 nhúng trên chuỗi. Đây là điều tôi đã kêu gọi kể từ cơn sốt ghi chép cuối cùng. Hệ sinh thái Bitcoin nên coi trọng giá trị của Bitcoin như một bus dữ liệu công cộng toàn cầu.

Giá trị của L1 như một bus dữ liệu chung toàn cầu

Kể từ mùa hè DeFi, toàn bộ lĩnh vực Crypto đã khám phá các ứng dụng mới ngoài DeFi. Cho dù đó là cơn sốt ghi danh Bitcoin hay cuộc thảo luận sôi nổi gần đây về Based Rollup, thì đều có thể hiểu là sự tái khám phá giá trị của L1 như một bus dữ liệu. Theo quan điểm 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 không cần cấp phép. Ví dụ, sàn giao dịch phi tập trung trong hệ sinh thái Crypto đã tận dụng tối đa blockchain như một Data Bus để đạt được sự kết nối phi tập trung, điều này khó có thể đạt được trực tiếp trong hệ thống tài chính truyền thống. Nếu bạn 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 tiền đơn giản lên các giao dịch giao thức ứng dụng để đạt được quyền không cần cấp phép ở cấp độ ứng dụng và phương pháp này ít xâm lấn nhất đối với các ứng dụng hiện có.

Bài viết này chủ yếu thảo luận về BBR theo góc nhìn 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 theo chế độ BBR sẽ được thảo luận chi tiết trong các bài viết sau. Một số liên kết liên quan được đính kèm ở cuối, bao gồm các bài viết lịch sử của tôi và các giải thích về Based Rollup theo các góc nhìn khác nhau của bạn bè trên Twitter.

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. Bitcoin Layer 2 nên được thực hiện như thế nào? https://x.com/jolestar/status/1717358817992995120 Tôi đã thiết kế kế hoạch ban đầu dựa trên cách L2 sử dụng trạng thái và dữ liệu trên Bitcoin L1. Một người bạn đã đề cập đến giải pháp Booster trong phần bình luận và cuối cùng đã áp dụng giải pháp Booster vào thực tế.

3. Dòng chữ này là lỗi hay là tính năng? https://x.com/jolestar/status/1732711942563959185 Bài viết này giải thích giá trị của các dòng chữ khắc theo góc nhìn về cách xây dựng L2, bao gồm vấn đề tương thích động cơ giữa L1 và L2.

4. Thảo luận về Based Rollup theo quan điểm của lý thuyết trừ @kerne l1 983 https://web3 caff.com/zh/archives/108241

5. Bài viết của @jason_chen 998 về Based Rollup https://x.com/jason_chen998/status/1799692331635048697

6. Dựa trên Báo cáo nghiên cứu Rollup Track https://research.web3 caff.com/zh/archives/22719

Liên kết gốc

Bài viết này có nguồn từ internet: Phân tích chuyên sâu về Based Booster Rollup: bối cảnh, thực hành và triển vọng

Có liên quan: Mật khẩu an toàn của PayFi trong cuộc cách mạng thanh toán bảo vệ cốt lõi của tài chính Web3

Bài viết này Hash (SHA 1): 8656ff83d95af1de9dab2b925597cf72c6f63c66 Số: Lianyuan Security Knowledge Số 032 Với sự phát triển liên tục của công nghệ blockchain, ngành tài chính đang trải qua một cuộc chuyển đổi chưa từng có. Trong bối cảnh này, một khái niệm mới nổi đã dần xuất hiện: PayFi (Tài chính thanh toán). Thuật ngữ này lần đầu tiên được Lily Liu, Chủ tịch Quỹ Solana, đề xuất tại hội nghị EthCC năm 2024 để khám phá một mô hình thanh toán và tài chính sáng tạo. Tầm nhìn của PayFi không chỉ là một hệ thống thanh toán dựa trên mật mãtiền tệ, mà còn hy vọng cung cấp cho người dùng các dịch vụ tài chính an toàn hơn, nhanh hơn và chi phí thấp hơn thông qua công nghệ phi tập trung kết hợp với giá trị thời gian của tiền tệ. 1. Khái niệm cốt lõi của PayFi: giá trị thời gian của tiền và tài chính phi tập trung PayFi là gì Lily Liu đã đề cập rằng động lực cốt lõi của PayFi là hiện thực hóa tầm nhìn ban đầu của Bitcoin…