Tiêu đề gốc: " Sự phát triển mô-đun của Rollup Layer2 》
Tác giả gốc: Jolestar, người đồng sáng lập Rooch
Điều này nỗ lực của bài viết Thảo luận về sự phát triển và tiến hóa của Rollup Layer2 từ góc độ tiến hóa, chủ yếu trả lời các câu hỏi sau:
Rollup Cách thức hoạt động
Sự phát triển theo mô-đun của Rollup
Các khả năng do tính mô-đun mang lại
Xu hướng kỹ thuật trong các ứng dụng mô-đun
Tóm tắt
Bộ ba vấn đề của blockchain luôn là vấn đề nan giải gây khó khăn cho ngành. Nếu chúng ta cho rằng blockchain Layer1 trước tiên phải đảm bảo tính “phân cấp” “và” bảo mật ", thì việc di chuyển giải pháp "khả năng mở rộng" từ Layer1 là một lựa chọn đương nhiên, do đó Layer2 đã được tạo. Vấn đề mới là làm thế nào để đảm bảo tính bảo mật của Layer2 thông qua Layer1.
Ban đầu, có ý tưởng thường xuyên ghi gốc cây trạng thái của ứng dụng Layer2 lên Layer1, để Xác minh trạng thái của ứng dụng thông qua bằng chứng trạng thái, tương tự như chứng chỉ dự trữ của sàn giao dịch. Tuy nhiên, bằng cách này, các bên thứ ba không thể xác minh một cách công khai rằng hai lần chuyển đổi trạng thái là chính xác.
Để tìm hiểu vấn đề này sâu hơn, chúng ta hãy trừu tượng hóa nó. Trạng thái của bất kỳ chương trình nào cũng có thể được thông qua Một biểu thức công thức chuyển trạng thái:
t+1 (t, T)
Công thức này xuất phát từ Sách vàng Ethereum, nhưng nó có thể đại diện cho bất kỳ chương trình nào. Ở đây đại diện cho chương trình và đại diện cho trạng thái. Trạng thái t+1 được tính toán bởi chương trình Y từ trạng thái t và giao dịch T. Giao dịch T đại diện cho đầu vào của chương trình. Tại bất kỳ thời điểm nào, nếu t là chắc chắn, chương trình Y là chắc chắn và T là chắc chắn thì t+1 là chắc chắn.
Vì vậy, để cung cấp khả năng xác minh công khai, điều quan trọng là Y phải được công khai. T phải được công khai và xác định tuần tự, đồng thời các trạng thái trung gian có thể được tính toán lại từ Y và T. Tính khả dụng công khai của các chương trình có thể đạt được thông qua nguồn mở. Điều quan trọng là làm thế nào để đảm bảo rằng T có sẵn công khai, điều này đưa ra khái niệm về tính khả dụng của dữ liệu (DA).
Tính khả dụng của dữ liệu cần có sổ cái công khai, bất biến để ghi lại các giao dịch ứng dụng. Đương nhiên, tôi nghĩ rằng sổ cái blockchain là một hệ thống như vậy, vì vậy các giao dịch của Layer2 được ghi lại vào Layer1 để đảm bảo tính khả dụng của dữ liệu.Đây là nguồn gốc của cái tên Rollup.
Vì vậy, hệ thống Lớp 2 cần có vai trò thu thập các giao dịch của người dùng, sắp xếp chúng và ghi chúng vào DA, vai trò này được gọi là Sequencer. Chuỗi giao dịch ở đây được gọi là Chuỗi giao dịch Canonical.
Tính sẵn có của dữ liệu được đảm bảo và mọi người đều có thể nhận được kết quả cuối cùng bằng cách chạy chương trình của riêng mình và thực hiện các giao dịch. Nhưng không có sự đồng thuận ở đây, bởi vì mọi người đều không chắc chắn liệu kết quả họ nhận được có phù hợp với kết quả của người khác hay không, suy cho cùng, lỗi phần mềm hoặc phần cứng cũng có thể dẫn đến dữ liệu không nhất quán. Vì vậy, cần có một vai trò khác là thường xuyên xuất bản gốc cây trạng thái sau khi thực hiện giao dịch để mọi người xác minh trạng thái của mình, vai trò này được gọi là Người đề xuất. Trạng thái của mỗi lần gửi ở đây cũng cấu thành một chuỗi trạng thái tương ứng với chuỗi giao dịch, được gọi là Chuỗi cam kết trạng thái.
Ở đây, chúng tôi đã đạt được khả năng xác minh của ứng dụng. Nếu kết quả hoạt động của ai đó không nhất quán với trạng thái do Người đề xuất đưa ra và được xác định rằng đó không phải là vấn đề của chính họ thì Người đề xuất đã gian lận hoặc mắc lỗi, làm sao người khác có thể biết được? Điều này đòi hỏi phải giới thiệu vai trò của Trọng tài. Trọng tài cần phải là bên thứ ba đáng tin cậy và hợp đồng trực tuyến có thể đóng vai trò này.
Có hai lựa chọn để phân xử:
p>
Mỗi khi Người đề xuất gửi một trạng thái, nó cũng cung cấp một bằng chứng hợp lệ (Bằng chứng hợp lệ) về sự chuyển đổi trạng thái giữa trạng thái trước đó và hợp đồng trọng tài trên chuỗi.kiểm tra. Bằng chứng hiệu quả thường được tạo ra thông qua công nghệ Zero Knowledge, được gọi là ZK Rollup.
Đầu tiên giả định kết quả của Người đề xuất là đúng, nhưng nếu phát hiện thấy không nhất quán thì Hợp đồng trọng tài sẽ đưa ra Bằng chứng gian lận để đưa ra phán quyết. Nếu hợp đồng trọng tài xác định Người đề xuất gian lận thì Người đề xuất sẽ bị trừng phạt và Chuỗi cam kết trạng thái sẽ được roll về trạng thái trước khi thực hiện giao dịch gian lận. Tất nhiên, để đảm bảo an ninh, một khoảng thời gian thử thách tương đối dài thường được đặt ra để đạt được sự chắc chắn cuối cùng trong việc giải quyết giao dịch trên chuỗi. Điều này được gọi là Tổng hợp lạc quan.
Chúng ta cũng cần nhận ra khả năng tương tác tài sản giữa Lớp 1 và Lớp 2. Vì vậy, một cầu nối giữa Layer1 và Layer2 đã được xây dựng để thực hiện xử lý tài sản thông qua bằng chứng trạng thái. Trạng thái của Layer2 trong Layer1 được đảm bảo bởi hợp đồng trọng tài của Layer 1. Chúng ta có thể nghĩ rằng sự an toàn của cây cầu này cũng được đảm bảo bởi hợp đồng trọng tài.
Tại thời điểm này, chúng tôi đã có được một hệ thống được bảo mật bởi Lớp 1 và có thể giao tiếp với Lớp 1 .. Lược đồ Rollup Layer2.

Tất nhiên, giải pháp Rollup cũng có một số thỏa hiệp:
Ghi giao dịch lên Lớp 1 có nghĩa là khả năng mở rộng của Lớp 2 vẫn bị giới hạn bởi kích thước khối của Lớp 1. Lấy Ethereum làm ví dụ, một Lớp 2 nhất định chiếm hoàn toàn tất cả các khối của Ethereum và TPS trung bình mà nó có thể cung cấp chỉ là vài trăm và khả năng mở rộng bị giới hạn bởi DA.
Để tiết kiệm phí gas, Sequencer sẽ ghi các giao dịch vào DA theo đợt, tuy nhiên, Sequencer có thể gian lận bằng cách điều chỉnh thứ tự các giao dịch trước khi ghi vào DA.
Dưới đây là bản tóm tắt về tính bảo mật và tính cuối cùng của giao dịch ở Lớp 2:
Nếu người dùng chạy nút Layer2 và thực thi nó một cách trung thực theo thứ tự các giao dịch DA, thì người dùng có thể coi giao dịch đó là It được xác nhận ngay lập tức và cuối cùng, bởi vì nếu kết quả thực thi của người dùng khác với của Người đề xuất, điều đó có nghĩa là Người đề xuất đang gian lận và cần khôi phục trạng thái trên chuỗi, cuối cùng sẽ giống với kết quả thực thi nút của chính người dùng. Điểm rủi ro chính ở đây nằm ở rủi ro đã đề cập trước đó là nếu dữ liệu được đồng bộ hóa từ Sequencer theo thời gian thực, Sequencer sẽ điều chỉnh thứ tự các giao dịch chưa được ghi vào DA.
Nếu người dùng không thể tự chạy nút và cần phải dựa vào nhà cung cấp RPC thì người dùng cần phải chịu một số rủi ro về lòng tin nhất định. Nhưng rủi ro này tương tự như rủi ro do người dùng tin tưởng vào các nút RPC Lớp 1 gây ra. Rủi ro bổ sung ở đây vẫn là rủi ro do Bộ sắp xếp thứ tự loại bỏ các giao dịch hoặc sắp xếp lại các giao dịch.
Nếu Người đề xuất mắc lỗi nhưng không có nút nào bắt đầu thử thách và vượt quá thời gian thử thách, thì trạng thái lỗi không thể được khôi phục và trạng thái chỉ có thể được sửa chữa thông qua sự đồng thuận xã hội cứng rắn cái nĩa.
Theo phân tích trước đó, trong giải pháp Rollup, nhiều hợp đồng trên chuỗi đảm nhận các chức năng khác nhau và đại diện cho các mô-đun khác nhau. Đương nhiên, người ta tự hỏi liệu mô-đun có thể được chia thành nhiều chuỗi để đạt được khả năng mở rộng cao hơn hay không. Đây là ý tưởng về blockchain mô-đun và Rollup mô-đun.
Modularization ở đây có hai ý nghĩa:
Thông qua thiết kế mô-đun, hệ thống trở thành một hệ thống có thể cắm được. Các nhà phát triển có thể lắp ráp các mô-đun để đáp ứng nhu cầu của các tình huống ứng dụng khác nhau.
Dựa trên khả năng được cung cấp bởi 1, việc triển khai lớp mô-đun không bị ràng buộc với cùng Lớp 1, dẫn đến khả năng mở rộng tốt hơn.
Chúng ta có thể nghĩ đến ba lớp mô-đun chính:
Lớp sẵn sàng dữ liệu (Data Availability): Đảm bảo rằng dữ liệu giao dịch của lớp thực thi có thể được lấy thông qua các phương tiện công cộng và đảm bảo trình tự giao dịch.
Lớp thanh toán (Settlement): thực hiện việc xử lý tài sản và trạng thái giữa Layer1 và Layer2. Nó chứa Chuỗi và Cầu nối Cam kết của Nhà nước.
Lớp trọng tài (Arbitration): Xác minh chứng chỉ gian lận và đưa ra phán quyết (Lạc quan) hoặc xác minh chứng chỉ hợp lệ (ZK). Lớp trọng tài phải có khả năng kiểm soát Chuỗi cam kết nhà nước.
Lợi ích chính của việc di chuyển chức năng DA sang một giải pháp độc lập là phí gas giao dịch của Lớp 2 giảm ít nhất một bậc độ lớn.
Từ góc độ bảo mật, mặc dù tính phân cấp của chuỗi DA yếu hơn Ethereum , Việc đảm bảo bảo mật của lớp DA chủ yếu dành cho các giao dịch trong giai đoạn thử thách, sau giai đoạn thử thách, DA chủ yếu nhằm tạo điều kiện cho các nút khác đồng bộ hóa dữ liệu, nhưng không đảm bảo bảo mật nên yêu cầu phân cấp có thể giảm xuống một cấp.
Chuỗi riêng DA có thể cung cấp băng thông lưu trữ cao hơn và chi phí lưu trữ thấp hơn, đồng thời được chia sẻ cho nhiều ứng dụng DA thực hiện các thiết kế chuyên dụng . Đây cũng là chỗ đứng vững chắc của các chuỗi DA hiện tại như Celestia và Polygon Avail.
Sau khi tách lớp DA, chúng ta có kiến trúc bên dưới:

Trong hình trên, DA chịu trách nhiệm lưu Chuỗi giao dịch Canonical, để lại một chuỗi cho Hàng đợi giao dịch L1ToL2 của Lớp 1 được sử dụng để triển khai giao tiếp tin nhắn giữa Lớp 1 và Lớp 2. Người dùng cũng có thể trực tiếp ghi các giao dịch vào Hàng đợi này để đảm bảo rằng Lớp 2 là Không được phép và Trình sắp xếp chuỗi không thể kiểm tra người dùng hoặc giao dịch.
Nhưng một vấn đề mới sẽ được đặt ra ở đây: Nếu Sequencer viết trình tự giao dịch của DA và Proposer If Trình tự giao dịch được thực hiện không nhất quán, làm thế nào để xác định hợp đồng trọng tài? Một giải pháp là tạo cầu nối liên chuỗi giữa chuỗi DA và chuỗi trọng tài để xác minh bằng chứng dữ liệu do chuỗi DA cung cấp trong hợp đồng trọng tài. Tuy nhiên, giải pháp này phụ thuộc vào việc triển khai các cầu nối chuỗi chéo giữa DA và các chuỗi khác và việc lựa chọn giải pháp của DA sẽ bị hạn chế. Một giải pháp khác là giới thiệu một bằng chứng sắp xếp.
Chúng ta có thể nghĩ rằng Sequencer thực sự là một phần của giải pháp DA. Nó tương đương với DA dành riêng cho ứng dụng, chủ yếu dựa trên các lý do sau:
Bộ sắp xếp chuỗi cần cung cấp các đảm bảo DA trong khoảng thời gian trước khi ghi hàng loạt vào chuỗi DA.
Trình sắp xếp chuỗi cần chịu trách nhiệm xác minh, phân loại và viết giao dịch cuối cùng cho DA.
Nếu Trình sắp xếp chuỗi được yêu cầu tạo Bằng chứng trình tự cho mỗi giao dịch, có thể giải quyết được hai vấn đề :
Đảm bảo cho các giao dịch chưa được ghi vào chuỗi DA, khiến Trình sắp xếp chuỗi không dám điều chỉnh thứ tự giao dịch hoặc loại bỏ chúng theo ý muốn. Nếu không có cầu nối chuỗi chéo giữa chuỗi DA và chuỗi trọng tài, cơ chế thử thách của Bằng chứng trình tự có thể được sử dụng để đảm bảo rằng dữ liệu luôn sẵn có.
Bằng chứng trình tự có các đặc điểm sau:
Nó mang chữ ký của Sequencer, chứng tỏ rằng nó được phát hành bởi một Sequencer nào đó. Nó có thể chứng minh vị trí của một giao dịch nhất định trong toàn bộ chuỗi giao dịch. Nó là một loại bằng chứng tích lũy. Việc tích lũy mỗi giao dịch sẽ tạo ra một kết quả tích lũy mới, kết quả này liên quan đến tất cả các giao dịch lịch sử trước giao dịch, gây khó khăn cho việc giả mạo. Một giải pháp thay thế cho bộ tích lũy là Bộ tích lũy Merkle, trong đó kết quả tích lũy được biểu thị dưới dạng gốc của cây Merkle.
Cách thức hoạt động của Bằng chứng trình tự:
Người dùng hoặc nút thực thi gửi giao dịch tới Sequencer , Sequencer trả về Sequence Proof cho người dùng và đồng bộ hóa nó với các nút khác. Nếu Trình sắp xếp chuỗi loại bỏ hoặc giả mạo thứ tự giao dịch trước khi gửi nó cho DA, người dùng hoặc các nút khác có thể gửi Bằng chứng trình tự cho hợp đồng trọng tài để trừng phạt Trình sắp xếp chuỗi. Hợp đồng trọng tài cần đọc gốc của bộ tích lũy giao dịch từ hợp đồng Chuỗi cam kết nhà nước để xác minh Bằng chứng trình tự.
Thảo luận theo tình huống:
Trình sắp xếp thứ tự đã loại bỏ hoặc sắp xếp lại giao dịch của người dùng. Điều này khiến Bộ sắp xếp chuỗi tạo ra hai Bằng chứng trình tự ở cùng một vị trí. Người dùng gửi Bằng chứng trình tự cho hợp đồng trọng tài và Trình sắp xếp trình tự cần cung cấp bằng chứng rằng giao dịch được bao gồm trong thư mục gốc của bộ tích lũy giao dịch mới nhất, nếu không cung cấp được thì Trình sắp xếp trình tự sẽ bị trừng phạt.
Người sắp xếp trình tự đã ghi giao dịch vào chuỗi DA không chính xác và âm mưu với Người đề xuất để che giấu giao dịch. Nếu có cầu nối giữa chuỗi trọng tài và chuỗi DA, việc xác minh sẽ được thực hiện thông qua cầu nối đó và Bộ sắp xếp chuỗi sẽ bị trừng phạt. Mặt khác, người dùng có thể bắt đầu thử thách và yêu cầu Trình sắp xếp chuỗi cung cấp bằng chứng về giao dịch tại một địa điểm nhất định cũng như thông tin gốc. Nhưng trong trường hợp này, hợp đồng trọng tài không thể xác định liệu người dùng có phải là kẻ thách thức ác ý hay không, vì vậy nếu Sequencer đưa ra dữ liệu thì nó sẽ không trừng phạt Sequencer. Đối với người dùng, những thách thức độc hại gây tổn hại cho người khác và chính họ, đồng thời thiếu động lực kinh tế.
Chúng tôi làm cho giao thức Lớp 2 an toàn hơn bằng cách giới thiệu Bằng chứng trình tự.
Việc chia Sequencer cho DA chỉ chịu trách nhiệm xác minh và sắp xếp các giao dịch, một lợi ích khác là dễ dàng thực hiện các giao dịch.

Khi xác minh giao dịch, bạn cần xác minh chữ ký và có đủ Gas hay không phí và Gas Việc xác minh phí tùy thuộc vào tiểu bang. Nếu chúng tôi cho phép một độ trễ nhất định (cấp thứ hai) giữa trạng thái mà giao dịch xác minh Trình sắp xếp phụ thuộc vào và trạng thái mới nhất để đảm bảo rằng giao dịch xác minh sẽ không bị chặn khi thực hiện giao dịch, thì việc xác minh Gas sẽ kém chính xác hơn và sẽ có nguy cơ bị tấn công DDoS. .
Nhưng chúng tôi cho rằng Sequencer thuộc về DA là một hướng đi đúng đắn nên rất xứng đáng với sự tham gia của chúng tôi học cao hơn. Ví dụ: phần DA của phí giao dịch có thể được tách ra và thể hiện thông qua UTXO (Sui Move Object), điều này có thể giảm chi phí phát hiện phí gas.
Bộ sắp xếp chuỗi sắp xếp các giao dịch và xuất chúng thành một hệ thống giao dịch, sau đó đồng bộ hóa chúng với Người đề xuất và các nút khác. Mỗi nút có thể chọn giải pháp song song dựa trên điều kiện máy chủ của riêng nó. Mỗi nút cần đảm bảo rằng: chỉ những giao dịch không có quan hệ nhân quả mới được thực hiện song song và các giao dịch có quan hệ nhân quả phải được thực hiện theo thứ tự của Sequencer, để kết quả cuối cùng sẽ nhất quán.
Người đề xuất cần thường xuyên gửi gốc của cây trạng thái và gốc của bộ tích lũy cho Nhà nước trên chuỗi Cam kết Hợp đồng chuỗi.
Vì vậy, chúng tôi có mức phí gas thấp, TPS cao và Lớp 2 mô-đun an toàn hơn : Rooch.

p>
MoveOS: Nó bao gồm MoveVM và StateDB, là công cụ lưu trữ trạng thái và thực thi của hệ thống. StateDB được xây dựng từ hai lớp cây Merkle thưa thớt và có thể cung cấp bằng chứng trạng thái. Theo phân tích trước đó, có thể kết luận rằng cây trạng thái và bằng chứng trạng thái là những thành phần không thể thiếu của ứng dụng Rollup.
RPC: Cung cấp các dịch vụ truy vấn bên ngoài, gửi giao dịch và đăng ký. Nó có thể tương thích với giao diện RPC của các chuỗi khác thông qua chế độ proxy.
Trình sắp xếp trình tự: Xác minh các giao dịch, giao dịch theo trình tự, cung cấp Bằng chứng trình tự và truyền các giao dịch đến Đường ống giao dịch.
Người đề xuất: Nhận các giao dịch từ Đường ống giao dịch, thực hiện chúng theo đợt và gửi chúng đến Chuỗi cam kết nhà nước trên chuỗi một cách thường xuyên.
Người thách thức: Nhận các giao dịch từ Đường ống giao dịch, thực hiện chúng theo đợt, so sánh chúng với Chuỗi cam kết cấp nhà nước và quyết định xem có nên bắt đầu thử thách hay không.
Giao diện DA & Giải quyết & Trọng tài: Trừu tượng hóa và đóng gói các lớp mô-đun khác nhau để đảm bảo rằng logic kinh doanh của lớp trên không bị ảnh hưởng khi chuyển đổi giữa các triển khai khác nhau.
Trong sơ đồ Tổng hợp lạc quan, hợp đồng trọng tài trên chuỗi xác định lỗi thực thi của giao dịch ngoài chuỗi như thế nào luôn là một vấn đề khó khăn. Ý tưởng ban đầu là thực hiện lại giao dịch Layer2 trên Layer1, nhưng vấn đề với giải pháp này là hợp đồng Layer1 cần mô phỏng việc thực hiện giao dịch Layer2, điều này rất tốn kém và cũng hạn chế độ phức tạp của giao dịch Layer2.
Cuối cùng, ngành đã tìm ra giải pháp bằng chứng tương tác. Bởi vì bất kỳ giao dịch phức tạp nào cuối cùng cũng sẽ được chuyển đổi thành các lệnh máy để thực thi, nếu tìm thấy các lệnh gây ra sự phân kỳ thì chúng ta chỉ cần mô phỏng việc thực hiện các lệnh trên chuỗi.
Cũng sử dụng công thức chuyển trạng thái ở trên:
t+1 (t,T)
Ở đây tượng trưng cho lệnh, T tượng trưng cho lệnh đầu vào, Biểu thị trạng thái bộ nhớ mà lệnh phụ thuộc vào. Nếu trong quá trình thực thi, một bằng chứng trạng thái được tạo cho mỗi trạng thái. Bên công tố và bên bào chữa có thể phát hiện ra điểm bất đồng m giữa hai bên thông qua tương tác và gửi trạng thái m-1 và hướng dẫn m cho hợp đồng trọng tài trực tuyến để thực hiện mô phỏng. được cho.
Vì vậy, câu hỏi còn lại là làm thế nào để tạo ra bằng chứng. Có hai lựa chọn chính: p>
Được triển khai trực tiếp trên máy ảo ngôn ngữ hợp đồng, chẳng hạn như AVM của Arbitrum và FuelVM của Fuel.
Triển khai trình mô phỏng dựa trên tập lệnh hiện có để cung cấp khả năng chứng minh trong trình mô phỏng. Chẳng hạn như khẩu pháo của Optimism dựa trên hướng dẫn MIPS, Nitro mới của Arbitrum dựa trên hướng dẫn WASM và OMO của Rooch dựa trên hướng dẫn MIPS.

OMO là một trình mô phỏng mã byte có mục đích chung với khả năng chứng minh trạng thái một bước. cho môi trường thực thi đa chuỗi. Với sự hỗ trợ của OMO, việc mô-đun hóa lớp trọng tài có thể đạt được. Bất kỳ chuỗi nào hỗ trợ hợp đồng Turing-Complete đều có thể mô phỏng các hướng dẫn OMO trong hợp đồng dưới dạng lớp trọng tài.
Ngành đang tranh luận xem cái nào tốt hơn giữa Optimistic Rollup và ZK Rollup, nhưng chúng tôi tin rằng việc kết hợp cả hai có thể mang lại lợi ích cho cả hai giải pháp.

Dựa trên giải pháp Optimistic trước đó, chúng tôi giới thiệu một vai trò mới, ZK Prover. Nó tạo ra các bằng chứng hợp lệ theo lô về trạng thái giao dịch do Người đề xuất gửi và gửi chúng đến hợp đồng trọng tài. Sau khi hợp đồng trọng tài được xác minh, có thể xác định rằng giao dịch đã đạt đến mức cuối cùng trên Lớp 1 và giao dịch rút tiền từ Lớp 2 sang Lớp 1 có thể được giải quyết.
Ưu điểm của giải pháp này:
Thông lượng tổng thể của Lớp 2 sẽ không bị giới hạn do các vấn đề về hiệu suất ZK. ZK có thể được sử dụng để rút ngắn chu kỳ thử thách Lạc quan và cải thiện trải nghiệm người dùng.
Trước khi giải pháp tăng tốc phần cứng và giải pháp của ZK hoàn thiện, trước tiên chúng ta có thể xây dựng một hệ sinh thái thông qua Optimistic và tại đồng thời Giải pháp mô-đun cuối cùng cho phép ZK được tích hợp liền mạch.
Nếu nghĩ sâu hơn về xu hướng mô-đun hóa, chúng tôi tự nhiên nghĩ rằng vì DA có thể được di chuyển sang các chuỗi khác nên lớp thanh toán cũng có thể được triển khai sang các chuỗi khác không?
Việc xử lý tài sản giữa Lớp 1 và Lớp 2 chủ yếu dựa vào hai thành phần, một là Cầu và một Đó chính là State Commitment Chain, khi giải quyết từ Bridge bạn cần dựa vào State Commitment Chain để xác minh chứng chỉ trạng thái của Layer2. Tất nhiên, Bridge có thể được triển khai trên nhiều chuỗi, nhưng Chuỗi cam kết nhà nước chỉ có thể có một phiên bản chính thức, được đảm bảo bởi hợp đồng trọng tài.

Hướng đi này vẫn cần nghiên cứu chuyên sâu nhưng đã có kế hoạch sơ bộ. Chuỗi cam kết nhà nước trên các chuỗi khác là hình ảnh phản chiếu của chuỗi trọng tài (Ethereum). Bản sao này không cần phải đồng bộ hóa tất cả Root trạng thái Layer2 với các chuỗi khác, nhưng người dùng có thể thực hiện ánh xạ thông qua bằng chứng trạng thái của Ethereum theo yêu cầu.
Tất nhiên, các chuỗi khác cũng cần có khả năng xác minh bằng chứng trạng thái về Ethereum, vì vậy họ cần biết State root trên Ethereum. Hiện tại, có hai tùy chọn để đồng bộ hóa trạng thái gốc trên Ethereum với các nút khác: 1. Dựa vào Oracle. 2. Nhúng nút nhẹ Ethereum và xác minh tiêu đề khối Ethereum.

Bằng cách này, chúng tôi có thể có được giải pháp Lớp 2 hỗ trợ giải quyết đa chuỗi nhưng được đảm bảo an toàn bởi Ethereum.
Sự khác biệt giữa giải pháp này và chuỗi chéo:
Nếu là giải pháp chuỗi chéo dựa vào chuỗi chuyển tiếp thì có thể coi Lớp 2 thay thế chuỗi chuyển tiếp và được một biện pháp bảo đảm được đảm bảo bởi hợp đồng trọng tài, lớp kế thừa.
Nếu đó là giải pháp chuỗi chéo trong đó các chuỗi xác minh chứng chỉ trạng thái của nhau thì giải pháp xử lý đa chuỗi và giải pháp kỹ thuật đồng bộ hóa gốc trạng thái chung của nó sẽ được đơn giản hóa hơn nhiều . Bởi vì trong giải pháp giải quyết đa chuỗi, yêu cầu đồng bộ gốc trạng thái là một chiều, chỉ cần đồng bộ từ chuỗi trọng tài sang các chuỗi khác chứ không cần đồng bộ với nhau.
Thông qua việc mô-đun hóa, các nhà phát triển có thể kết hợp các ứng dụng khác nhau thông qua Rooch.
Rooch Ethereum Layer2 = Rooch + Ethereum(Thỏa thuận+Trọng tài) + DA. Đây là mạng đầu tiên Rooch sẽ chạy. Cung cấp nền tảng vận hành Move được đảm bảo bởi bảo mật Ethereum có thể tương tác với các tài sản trên Ethereum. Nó có thể được mở rộng sang thanh toán đa chuỗi trong tương lai.
Rooch Layer3 Rollup DApp = Rooch + Hợp đồng di chuyển DApp + Rooch Ethereum Layer2(Thỏa thuận + Trọng tài) + DA Nếu ứng dụng triển khai việc dàn xếp và phân xử của nó lên Rooch Layer2 , nó là một ứng dụng Rooch Layer3.
XChain Rollup DApp = Rooch + Hợp đồng di chuyển DApp + XChain(Thỏa thuận + Trọng tài) + DA Bất kỳ chuỗi nào cũng có thể sử dụng Rooch để cung cấp cho các nhà phát triển một bộ DApp tổng hợp bộ công cụ dành cho ngôn ngữ Move. Các nhà phát triển chỉ cần viết logic ứng dụng của riêng họ thông qua ngôn ngữ Move và sau đó họ có thể chạy ứng dụng Rollup trong một môi trường độc lập được XChain bảo mật và đảm bảo, đồng thời tài sản của họ có thể được tương tác với XChain. Tất nhiên, điều này cần được phát triển với sự cộng tác của các nhà phát triển của từng chuỗi công khai.
Sovereign Rollup DApp = Rooch + Hợp đồng di chuyển DApp + DA Ứng dụng cũng có thể sử dụng Rooch làm SDK tổng hợp có chủ quyền mà không cần triển khai các hợp đồng Cầu nối và Trọng tài. Chuỗi cam kết nhà nước cũng được lưu trong DA. Khả năng xác minh được đảm bảo và tính bảo mật được đảm bảo bởi sự đồng thuận xã hội.
Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave) SCP tương tự như Sovereign Rollup. SCP yêu cầu mã ứng dụng cũng phải được lưu vào DA. . Trong Rooch, việc triển khai và nâng cấp hợp đồng là các giao dịch và mã hợp đồng sẽ được ghi vào lớp DA trong quá trình giao dịch, vì vậy chúng tôi tin rằng nó đáp ứng các tiêu chuẩn của SCP.
Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOS có thể được nhúng vào môi trường vận hành của bất kỳ chuỗi nào dưới dạng môi trường vận hành Move độc lập. hoặc một chuỗi công khai mới.
Các dự án không có blockchain Các dự án không có blockchain có thể sử dụng MoveOS làm dự án có khả năng xác minh dữ liệu và sử dụng cơ sở dữ liệu để lưu trữ khả năng chứng minh. Ví dụ: sử dụng nó để xây dựng hệ thống blog cục bộ và cấu trúc dữ liệu và logic nghiệp vụ được thể hiện thông qua Move. Khi cơ sở hạ tầng hoàn thiện trong tương lai, nó có thể được kết nối trực tiếp với hệ sinh thái blockchain. Một ví dụ khác, nó có thể được sử dụng để cung cấp các dịch vụ FaaS trong điện toán đám mây, các nhà phát triển sử dụng Move để viết các hàm trong FaaS, nền tảng ở trạng thái được quản lý và các hàm giữa những người dùng cũng có thể được kết hợp và gọi lẫn nhau. Nhiều khả năng hơn cần được khám phá.
Giải pháp mô-đun của Rooch có thể được điều chỉnh cho phù hợp với các loại và giai đoạn ứng dụng khác nhau. Ví dụ: trước tiên, các nhà phát triển có thể xác minh ý tưởng của họ trên Rooch Ethereum Layer2 bằng cách triển khai các hợp đồng và sau khi trưởng thành, hãy di chuyển ứng dụng sang một Bản tổng hợp dành riêng cho ứng dụng độc lập được xây dựng trên Rooch.
Hoặc nhà phát triển có thể trực tiếp khởi động ứng dụng thông qua phương thức Sovereign Rollup vì yêu cầu bảo mật sớm của ứng dụng. Giá trị không cao, không cần trao đổi tài sản với các chuỗi khác mà phải được kiểm chứng trước. Khi các ứng dụng phát triển, nhu cầu về các tài sản có khả năng tương tác và yêu cầu bảo mật ngày càng cao hơn, tại thời điểm này, các mô-đun giải quyết và phân xử có thể được kích hoạt để đảm bảo tính bảo mật của tài sản.
p>
Có thể thấy từ phân tích trước rằng dù phương pháp kết hợp nào cũng phụ thuộc vào DA. Vai trò của DA trong các ứng dụng phi tập trung tương tự như nền tảng ghi nhật ký của hệ thống Web2, có thể được sử dụng để kiểm tra, hỗ trợ phân tích dữ liệu lớn, đào tạo AI, v.v. Sẽ có nhiều ứng dụng và dịch vụ được xây dựng xung quanh DA trong tương lai. Hiện tại đã có Celestia, Polygoin và trong tương lai sẽ có EigenLayer, Ethereum danksharding, v.v.
Dựa trên phân tích trước đó, chúng tôi kết luận rằng vai trò của Trình sắp xếp chuỗi phải là một phần của DA. Nếu DA Lớp có thể cung cấp khả năng xác minh giao dịch cho các ứng dụng và có đủ hiệu suất thì trên thực tế, DA hoàn toàn có thể đảm nhận trách nhiệm của Sequencer và người dùng có thể trực tiếp ghi giao dịch vào DA. Tất nhiên, liệu Token của ứng dụng có thể được sử dụng để thanh toán phí gas của DA hay không lại là một vấn đề khác cần được giải quyết.
p>
Các hình thức ứng dụng mới sẽ thúc đẩy sự bùng nổ của các ngôn ngữ lập trình mới, điều này đã được chứng minh trong kỷ nguyên Web2. Và Move sẽ trở thành ngôn ngữ tốt nhất để xây dựng Web3 DApps. Ngoài những đặc điểm về ngôn ngữ của bản thân Move, nó còn dựa trên những lý do sau:
Các DApp sử dụng cùng một ngôn ngữ có thể nhanh chóng tích lũy các thư viện cơ bản cần thiết cho các ứng dụng để tạo thành hiệu ứng tổng hợp sinh thái. Vì vậy, việc hỗ trợ nhiều ngôn ngữ không phải là một chiến lược tốt ngay từ đầu.
Các ứng dụng phi tập trung ít nhất phải đảm bảo khả năng xác minh và ngôn ngữ hợp đồng thông minh có thể cho phép các nhà phát triển giảm bớt rất nhiều gánh nặng tinh thần trong việc đảm bảo khả năng xác minh.
Tính độc lập của nền tảng Move giúp dễ dàng thích ứng với các nền tảng và ứng dụng khác nhau.
Trạng thái Move có cấu trúc, có lợi cho việc biểu hiện cấu trúc dữ liệu và truy xuất bộ nhớ của DApp.
Tôi bước chân vào lĩnh vực blockchain vào cuối năm 2017. Vào thời điểm đó, có rất nhiều đội ngũ trong ngành đang cố gắng xây dựng các ứng dụng trong lĩnh vực blockchain. Thật không may, cơ sở hạ tầng vẫn chưa hoàn thiện vào thời điểm đó và ngành vẫn chưa tìm ra mô hình có thể nhân rộng để xây dựng ứng dụng.Hầu hết các dự án ứng dụng đều kết thúc trong thất bại, gây ảnh hưởng nặng nề đến các nhà phát triển và nhà đầu tư. Các ứng dụng trên blockchain nên được xây dựng như thế nào? Câu hỏi này đã khiến tôi suy nghĩ suốt 5 năm.
Giờ đây, với sự trưởng thành của Lớp 1, Lớp 2, hợp đồng thông minh và cơ sở hạ tầng mô-đun, câu trả lời cho câu hỏi này là cũng dần dần trở nên rõ ràng.
Tôi hy vọng rằng trong sự bùng nổ sắp tới của Web3 DApps, Rooch có thể giúp các nhà phát triển xây dựng ứng dụng nhanh hơn và thực sự triển khai chúng.
Liên kết gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia