Bài viết này cố gắng thảo luận về sự phát triển và tiến hóa của Rollup Layer 2 từ góc độ tiến hóa và chủ yếu trả lời các câu hỏi sau:
Cách hoạt động của bản tổng hợp:
Sự phát triển mô-đun của rollups
Tính mô-đun mở ra khả năng
Xu hướng công nghệ trong các ứng dụng mô-đun
tóm tắt
Cách hoạt động của Rollups
“Bộ ba tiến thoái lưỡng nan” của blockchain luôn là một vấn đề khó khăn đối với ngành công nghiệp và nếu chúng ta tin rằng các blockchain Lớp 1 trước tiên phải đảm bảo “phi tập trung” và “bảo mật”, thì việc di chuyển giải pháp “khả năng mở rộng” từ Lớp 1 là một lựa chọn tự nhiên, do đó Lớp 2. Thách thức mới là làm thế nào để đảm bảo tính bảo mật của Lớp 2 đến Lớp 1.
Ban đầu, có một ý tưởng định kỳ viết thư mục gốc của cây trạng thái của ứng dụng Lớp 2 sang Lớp 1, để trạng thái của ứng dụng có thể được xác minh bằng bằng chứng trạng thái, tương tự như bằng chứng dự trữ trên nền tảng giao dịch. Tuy nhiên, phương pháp này không thể được thực hiện bởi bên thứ ba để xác minh rằng hai quá trình chuyển đổi trạng thái là chính xác theo cách công khai.
Để đào sâu hơn vào vấn đề này, hãy trừu tượng hóa rằng trạng thái của bất kỳ chương trình nào cũng có thể được biểu thị bằng công thức chuyển đổi 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 là viết tắt của chương trình, đại diện cho nhà nước. Trạng thái t + 1 được tính theo 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. Bất cứ lúc nào, nếu t là xác định, chương trình Y là xác định và T là xác định, thì t + 1 là xác định.
Vì vậy, để cung cấp khả năng xác minh công khai, điều quan trọng là Y có sẵn công khai, rằng tất cả T trong lịch sử đều có sẵn công khai và theo thứ tự, và trạng thái trung gian có thể được tính toán lại bởi Y và T. Tính khả dụng công khai của chương trình có thể đạt được thông qua nguồn mở và chìa khóa là làm thế nào để đảm bảo tính khả dụng công khai của T, giới thiệu khái niệm về tính sẵn có của dữ liệu (DA).
Tính khả dụng của dữ liệu yêu cầu một sổ cái công khai, bất biến để ghi lại các giao dịch của ứng dụng. Đương nhiên, sổ cái blockchain là một hệ thống như vậy, vì vậy các giao dịch của Lớp 2 được ghi lại vào Lớp 1 để đảm bảo tính khả dụng của dữ liệu, đó là nơi tên của Rollup bắt nguồn.
Do đó, cần phải có một vai trò trong hệ thống Lớp 2 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 và vai trò này được gọi là Trình sắp xếp. Trình tự các giao dịch ở đây được gọi là Canonical Transaction Chain.
Tính khả dụng của dữ liệu được đảm bảo và mọi người đều có thể có được trạng thái cuối cùng bằng cách tự chạy chương trình để thực hiện 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ả của họ có giống với kết quả của những người khác hay không, xét cho cùng, lỗi phần mềm hoặc phần cứng cũng có thể gây ra sự không nhất quán về dữ liệu. Do đó, một vai trò khác là cần thiết để xuất bản gốc cây trạng thái sau khi giao dịch được thực hiện một cách thường xuyên để mọi người xác minh trạng thái của họ và vai trò này được gọi là Proposer. Trạng thái của mỗi cam kết ở đây cũng tạo 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.
Tại thời điểm này, chúng tôi đã đạt đến khả năng xác minh của ứng dụng. Nếu kết quả của ai đó không phù hợp với trạng thái của bài dự thi Proposer và được xác định rằng đó không phải là vấn đề của họ, thì Proposer đang gian lận hoặc sai, làm thế nào để bạn cho người khác biết về nó? Trọng tài cần phải là bên thứ ba đáng tin cậy và hợp đồng trên chuỗi có thể đảm nhận vai trò này.
Có hai lựa chọn cho trọng tài:
Mỗi khi Người đề xuất gửi một trạng thái, nó cũng cung cấp Bằng chứng hợp lệ về quá trình chuyển đổi trạng thái từ trạng thái trước đó, được xác minh bằng hợp đồng trọng tài trên chuỗi. Bằng chứng hợp lệ thường được tạo bằng công nghệ không có kiến thức, được gọi là ZK Rollup.
Giả định rằng kết quả của Proposer là chính xác, nhưng nếu tìm thấy sự không nhất quán, Bằng chứng gian lận sẽ được đệ trình và hợp đồng trọng tài quyết định. Nếu hợp đồng đại biểu xác định rằng Người đề xuất gian lận, Người đề xuất sẽ bị phạt và Chuỗi cam kết của Nhà nước được quay trở lại trạng thái trước khi 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 thiết lập để đạt được tính cuối cùng của việc giải quyết giao dịch trên chuỗi. Đây được gọi là một rollup lạc quan.
Chúng ta cũng cần triển khai khả năng tương tác tài sản giữa Lớp 1 và Lớp 2. Do đó, một cầu nối giữa Lớp 1 và Lớp 2 được xây dựng và việc giải quyết tài sản được thực hiện thông qua bằng chứng về nhà nước. Trạng thái của Layer 2 trong Layer 1 được đảm bảo bởi hợp đồng trọng tài của Layer 1, và chúng ta có thể giả định rằng tính 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.
Cho đến nay, chúng ta có một giải pháp Rollup Layer 2 được đảm bảo bởi Layer 1 và có thể tương tác với Layer 1.
Tất nhiên, có một số thỏa hiệp được thực hiện bởi giải pháp Rollup:
Ghi các giao dịch vào 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ụ, Lớp 2 chiếm hoàn toàn tất cả các khối Ethereum và TPS trung bình có thể được cung cấp chỉ 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 ghi các giao dịch cho DA theo lô và trước khi ghi vào DA, Sequencer có thể gian lận bằng cách điều chỉnh thứ tự của các giao dịch.
Dưới đây là tóm tắt về bảo mật Lớp 2 và tính cuối cùng của các giao dịch:
Nếu người dùng chạy một nút Lớp 2 và thực hiện trung thực thứ tự giao dịch của DA, người dùng có thể cho rằng giao dịch được xác nhận ngay lập tức và hoàn tất, bởi vì nếu kết quả thực thi của người dùng khác với kết quả của Proposer, điều đó có nghĩa là Proposer gian lận và cần phải khôi phục trạng thái của chuỗi, và kết quả sẽ giống như kết quả của chính nút của người dùng. Rủi ro chính ở đây là rủi ro đã đề cập trước đó của Sequencer điều chỉnh thứ tự các giao dịch chưa được ghi vào DA nếu dữ liệu được đồng bộ hóa từ Sequencer trong thời gian thực.
Nếu người dùng không thể tự chạy nút, anh ta cần dựa vào nhà cung cấp RPC và người dùng cần phải chịu một rủi ro tin cậy nhất định. Tuy nhiên, rủi ro này tương tự như rủi ro gây ra bởi người dùng tin tưởng các nút RPC trong Lớp 1. Rủi ro bổ sung ở đây vẫn là rủi ro Sequencer bỏ hoặc sắp xếp lại các giao dịch.
Nếu Proposer mắc lỗi, nhưng không có nút nào bắt đầu thách thức và vượt quá thời gian thử thách, trạng thái sai không thể được khôi phục và trạng thái chỉ có thể được khắc phục thông qua hard fork đồng thuận xã hội.
Sự phát triển mô-đun của rollups
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. Ý tưởng tự nhiên là 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. Đó là ý tưởng đằng sau các blockchain mô-đun và các bản tổng hợp mô-đun.
Mô-đun có hai ý nghĩa ở đây:
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 kịch bản ứng dụng khác nhau.
Dựa trên các 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 một Lớp 1, dẫn đến khả năng mở rộng tốt hơn.
Chúng ta có thể nghĩ về ba lớp mô-đun chính:
Tính khả dụng của dữ liệu: Đảm bảo rằng dữ liệu giao dịch của lớp thực thi có thể được lấy một cách công khai và chuỗi các giao dịch được đảm bảo.
Giải quyết: Giải quyết tài sản và trạng thái giữa Lớp 1 và Lớp 2. Nó chứa Chuỗi cam kết nhà nước và Cầu nối.
Trọng tài: Xác minh bằng chứng gian lận và đưa ra phán quyết (Lạc quan) hoặc xác minh bằng chứng hợp lệ (ZK). Lớp đại biểu cần có khả năng thao túng Chuỗi cam kết của Nhà nước.
DA mô-đun
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 Lớp 2 được giảm ít nhất một mức độ lớn.
Từ góc độ bảo mật, ngay cả khi sự phân cấp của chuỗi DA yếu hơn so với Ethereum, việc đảm bảo an toàn trong lớp DA chủ yếu là giao dịch trong giai đoạn thử thách.
Các 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 và được thiết kế đặc biệt cho nhiều ứng dụng để chia sẻ DA. Đây cũng là chỗ đứng của các chuỗi DA hiện tại như Celestia và Polygon Avail.
Sau khi tách layer DA, chúng ta có được kiến trúc của sơ đồ sau:
Trong hình trên, DA chịu trách nhiệm lưu Chuỗi giao dịch Canonical và Hàng đợi giao dịch L1ToL2 được để lại cho Layer1 để nhận ra giao tiếp thông điệp giữa Layer1 và Layer2 và người dùng cũng có thể viết các giao dịch trực tiếp vào hàng đợi này để đảm bảo rằng Layer2 là Permissionless và Sequencer không thể kiểm tra người dùng hoặc giao dịch.
Một giải pháp là có cầu nối xuyê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 thực hiện 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 các giải pháp DA sẽ bị hạn chế. Một lựa chọn khác là giới thiệu bằng chứng sắp xếp.
Bằng chứng trình tự
Chúng ta có thể nghĩ về Sequencer thực sự là một phần của lược đồ DA và nó tương đương với DA dành riêng cho ứng dụng vì những lý do sau:
Sequencer cần cung cấp đảm bảo DA cho khoảng thời gian trước khi ghi hàng loạt vào chuỗi DA.
Sequencer chịu trách nhiệm xác thực các giao dịch, trình tự và cuối cùng ghi chúng vào DA.
Nếu bạn yêu cầu Sequencer tạo Sequence Proof cho mỗi giao dịch, bạn có thể giải quyết hai vấn đề:
Cung cấp bảo lãnh cho các giao dịch chưa được ghi vào chuỗi DA, để Sequencer không dám tùy tiện điều chỉnh thứ tự giao dịch hoặc loại bỏ chúng. Nếu không có cầu nối chuỗi chéo giữa chuỗi DA và chuỗi đại biểu, dữ liệu có thể được đảm bảo có sẵn thông qua cơ chế thách thức của Bằng chứng trình tự.
Sequence Proof có các tính năng sau:
Nó mang chữ ký của Sequencer, chứng minh rằng nó được phát hành bởi một Sequencer. Nó chứng minh vị trí của một giao dịch trong toàn bộ chuỗi giao dịch. Nó là một loại bằng chứng tích lũy. Mỗi giao dịch được cộng lại để tạo ra một kết quả mới tương quan với tất cả các giao dịch lịch sử trước đó, gây khó khăn cho việc giả mạo. Một trong những lựa chọn cho bộ tích lũy là Bộ tích lũy Merkle, dẫn đến dạng rễ của cây Merkle.
Cách hoạt động của Sequence Proof:
Người dùng hoặc nút thực thi gửi giao dịch cho Sequencer và Sequencer trả về Bằng chứng trình tự 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 chúng cho DA, người dùng hoặc các nút khác có thể phạt Trình sắp xếp chuỗi bằng cách gửi Bằng chứng trình tự cho hợp đồng đại biểu. Hợp đồng đại biểu 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ự.
Hãy thảo luận về các tình huống sau:
Trình sắp xếp chuỗi loại bỏ hoặc sắp xếp lại các giao dịch của người dùng. Điều này khiến Sequencer tạo ra hai Sequence Proof ở cùng một vị trí. Khi người dùng gửi Bằng chứng trình tự cho hợp đồng trọng tài, Sequencer 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 và nếu không thể, Trình sắp xếp chuỗi sẽ bị phạt.
Sequencer đã không viết đúng các giao dịch vào chuỗi DA và âm mưu với Proposer để che giấu các giao dịch. Nếu chuỗi đại biểu và chuỗi DA có cầu nối, cầu nối được sử dụng để xác thực nó, phạt bộ giải trình tự. Nếu không, người dùng có thể thách thức Sequencer cung cấp bằng chứng về giao dịch tại một địa điểm nhất định, cùng với thông tin ban đầu. Tuy nhiên, trong trường hợp này, hợp đồng trọng tài không thể xác định người dùng có phải là một thách thức độc hại hay không, vì vậy nếu Sequencer cung cấp dữ liệu, nó không phạt Sequencer. Đối với người dùng, những thách thức độc hại làm tổn thương người khác và chính họ, và cũng 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 Sequence Proof.
Đường ống giao dịch và thực hiện song song
Một lợi ích khác của việc chia Sequencer thành các DA, chỉ chịu trách nhiệm xác thực và sắp xếp thứ tự các giao dịch, là dễ dàng hợp lý hóa các giao dịch và thực hiện song song.
Khi xác minh giao dịch, bạn cần xác minh chữ ký và liệu có đủ phí gas hay không, và việc xác minh phí gas cần phải phụ thuộc vào tiểu bang. Nếu chúng tôi cho phép Sequencer cho phép độ trễ (tính bằng giây) giữa trạng thái mà giao dịch xác minh phụ thuộc vào và trạng thái mới nhất để đảm bảo rằng giao dịch xác thực không bị chặn bởi giao dịch thực hiện, xác thực gas sẽ không chính xác và có nguy cơ bị tấn công DDoS.
Nhưng chúng tôi nghĩ rằng trở thành DA là hướng đi đúng đắn cho Sequencer, vì vậy nó đáng để xem xét thêm. Ví dụ: bạn có thể chia phần DA của phí giao dịch và thể hiện nó thông qua Sui Move Object (UTXO), điều này có thể làm giảm chi phí phát hiện phí gas.
Sequencer sắp xếp các giao dịch và xuất chúng vào một đường ống giao dịch, sau đó được đồng bộ hóa với Proposer và các nút khác. Mỗi nút có thể chọn một sơ đồ song song theo tình huống máy chủ riêng của nó. Mỗi nút cần đảm bảo rằng chỉ các giao dịch không có mối quan hệ nhân quả mới được song song và các giao dịch có mối quan hệ nhân quả phải được thực hiện theo thứ tự Trình tự và kết quả cuối cùng sẽ nhất quán.
Người đề xuất cần định kỳ cam kết gốc của cây trạng thái, cũng như gốc của bộ tích lũy cho hợp đồng Chuỗi cam kết trạng thái trên chuỗi.
Vì vậy, chúng tôi nhận được một Lớp 2 mô-đun với phí gas thấp, TPS cao và bảo mật hơn: Rooch.
MoveOS: Nó chứa MoveVM và StateDB, là công cụ thực thi và lưu trữ trạng thái của hệ thống. StateDB được xây dựng từ hai lớp cây Merkle thưa thớt cung cấp bằng chứng về trạng thái. Dựa trên 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à thành phần không thể thiếu của các ứng dụng tổng hợp.
RPC: Cung cấp các truy vấn bên ngoài, gửi giao dịch và đăng ký dịch vụ. Giao diện RPC có thể tương thích với các chuỗi khác có thể được môi giới.
Trình sắp xếp: Xác thực các giao dịch, chuỗi giao dịch, cung cấp bằng chứng trình tự và xuất các giao dịch ra Quy trình giao dịch.
Người đề xuất: Nhận các giao dịch từ Quy trình giao dịch, thực hiện chúng theo lô và gửi chúng đến Chuỗi cam kết trạng thái 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 lô và so sánh chúng với Chuỗi cam kết trạng thái để quyết định có khởi chạy thử thách hay không.
DA &; Settlement &; Arbitration Interface: Trừu tượng hóa và đóng gói các lớp mô-đun khác nhau để đảm bảo rằng việc chuyển đổi giữa các triển khai khác nhau không ảnh hưởng đến logic nghiệp vụ lớp trên.
Bằng chứng gian lận tương tác với hỗ trợ đa chuỗi
Trong sơ đồ rollup lạc quan, làm thế nào hợp đồng trọng tài on-chain xác định rằng lỗi thực hiện giao dịch off-chain luôn là một vấn đề khó khăn. Ý tưởng ban đầu là thực hiện lại giao dịch Layer 2 trên Layer 1, nhưng vấn đề với giải pháp này là hợp đồng Layer 1 cần mô phỏng việc thực hiện giao dịch Layer 2, rất tốn kém và sẽ hạn chế sự phức tạp của giao dịch Layer 2.
Cuối cùng, ngành công nghiệp đã khám phá một chương trình 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 sẽ được chuyển đổi thành thực thi lệnh máy, nếu chúng ta tìm thấy một lệnh tạo ra sự phân kỳ, chúng ta chỉ cần mô phỏng việc thực hiện lệnh trên chuỗi.
Cũng sử dụng công thức chuyển đổi trạng thái ở trên:
t+1 (t, T)
Ở đây T là viết tắt của lệnh và T là viết tắt của đầu vào lệnh, đại diện cho trạng thái bộ nhớ mà lệnh phụ thuộc vào. Nếu trong quá trình thực hiện, hãy tạo chứng chỉ trạng thái cho mỗi tệp . Thông qua tương tác, bên công tố và người bào chữa có thể tìm ra điểm bất đồng m giữa hai bên, đồng thời gửi trạng thái của m-1 và hướng dẫn m đến hợp đồng trọng tài on-chain để thực hiện mô phỏng, và hợp đồng trọng tài có thể được xác định sau khi nó được thực hiện.
Vì vậy, câu hỏi còn lại là làm thế nào để tạo ra các bằng chứng, và có hai lựa chọn chính:
Nó được triển khai trực tiếp trong 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ó và cung cấp khả năng chứng minh trong trình mô phỏng. Các ví dụ bao gồm pháo dựa trên MIPS của Optimism, Nitro dựa trên WASM mới của Arbitrum và OMO dựa trên MIPS của Rooch.
OMO là một trình mô phỏng bytecode đa năng với khả năng chứng minh trạng thái một bước, được thiết kế cho các môi trường thực thi đa chuỗi. Với sự hỗ trợ của OMO, tính mô-đun của lớp đại biểu có thể được thực hiện. 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 của OMO trong hợp đồng dưới dạng lớp đại biểu.
ZK + Sơ đồ kết hợp lạc quan
Đã có rất nhiều cuộc tranh luận trong ngành về giá trị củ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 cho bạn những điều tốt nhất của cả hai thế giới.
Trên cơ sở giải pháp Lạc quan trước đó, chúng tôi giới thiệu một nhân vật mới, ZK Prover. Nó tạo ra bằng chứng hợp lệ về tình trạng của các giao dịch do Người đề xuất gửi theo lô và gửi chúng cho 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 quyết định cuối cùng trên Tuyến 1 và giao dịch rút tiền từ Lớp 2 sang Tuyến 1 có thể được giải quyết.
Ưu điểm của phương pháp này:
Các vấn đề về hiệu suất ZK sẽ không giới hạn thông lượng tổng thể của Lớp 2. ZK có thể rút ngắn chu kỳ thử thách của Optimistic và cải thiện trải nghiệm người dùng.
Trước khi giải pháp và tăng tốc phần cứng của ZK trưởng thành, chúng ta có thể xây dựng một hệ sinh thái thông qua Optimistic và giải pháp mô-đun có thể làm cho ZK cuối cùng được tích hợp liền mạch.
Giải quyết đa chuỗi
Nếu chúng ta nghĩ xa hơn về xu hướng mô-đun, thật tự nhiên khi nghĩ rằng vì DA có thể được di chuyển sang các chuỗi khác, lớp giải quyết cũng có thể được triển khai cho các chuỗi khác không?
Việc xử lý tài sản giữa tầng 1 và tầng 2 chủ yếu phụ thuộc vào 2 thành phần, một là Cầu nối và hai là Chuỗi cam kết nhà nước. Cầu nối tất nhiên có thể được triển khai cho nhiều chuỗi, nhưng Chuỗi cam kết nhà nước chỉ có thể có một phiên bản có thẩm quyền, được bảo đảm bằng hợp đồng đại biểu.
Hướng đi này vẫn cần được nghiên cứu 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 Ethereum. Hình ảnh này không cần đồng bộ hóa tất cả Layer2 State Root với các chuỗi khác, nhưng được người dùng ánh xạ thông qua bằng chứng trạng thái theo yêu cầu của Ethereum.
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 trên Ethereum, vì vậy bạn cần biết gốc của trạng thái trên Ethereum. Hiện tại, có hai kịch bản để đồng bộ hóa gốc trạng thái trên Ethereum với các nút khác: 1. Dựa vào Oracle. 2. Nhúng nút ánh sáng Ethereum và xác minh tiêu đề khối của Ethereum.
Bằng cách này, chúng ta có thể có được giải pháp Lớp 2 hỗ trợ thanh toán đa chuỗi, nhưng tính bảo mật được đảm bảo 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 rơle thì có thể coi là Lớp 2 thay thế chuỗi chuyển tiếp và là lớp chuyển tiếp có bảo mật được đảm bảo bởi hợp đồng trọng tài.
Nếu đó là sơ đồ chuỗi chéo xác minh bằng chứng về trạng thái giữa các chuỗi, sơ đồ giải quyết đa chuỗi chia sẻ sơ đồ kỹ thuật đồng bộ hóa gốc trạng thái với nó, nhưng nó được đơn giản hóa nhiều. Bởi vì trong sơ đồ giải quyết đa chuỗi, yêu cầu đồng bộ hóa của gốc trạng thái là một chiều, và nó chỉ cần được đồng bộ hóa từ chuỗi đại biểu sang các chuỗi khác, không phải hai bởi hai.
Tính mô-đun mở ra các khả năng
Thông qua tính mô-đun, các nhà phát triển có thể kết hợp các ứng dụng khác nhau với Rooch.
Rooch Ethereum Lớp 2 = Rooch + Ethereum (Giải quyết + Trọng tài) + DA。 Đây là mạng mà Rooch sẽ chạy ngay từ đầu. Cung cấp nền tảng thời gian chạy Move được đảm bảo bởi bảo mật Ethereum và có thể tương tác với các tài sản trên Ethereum. Trong tương lai, nó có thể được mở rộng để giải quyết đa chuỗi.
Rooch Layer3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer2 (Giải quyết + Trọng tài) + DA Nếu một ứng dụng triển khai giải quyết và trọng tài của riêng mình cho Rooch Layer 2, nó là một ứng dụng Rooch Layer 3.
XChain Rollup DApp = Rooch + DApp Move Contract + XChain (Giải quyết + Trọng tài) + DA Bất kỳ chuỗi nào cũng có thể cung cấp cho các nhà phát triển một bộ công cụ DApp Rollup dựa trên ngôn ngữ Move thông qua Rooch. 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 để chạy ứng dụng rollup trong một môi trường độc lập được bảo mật và bảo vệ bởi XChain và các tài sản có thể tương thích với XChain. Tất nhiên, điều này cần được phát triển với sự hợp tác của các nhà phát triển của mỗi chuỗi công khai.
Sovereign Rollup DApp = Rooch + DApp Move Contract + DA ứng dụng cũng có thể sử dụng Rooch làm SDK Sovereign Rollup, mà không cần triển khai hợp đồng Bridge và Arbitration, và State Commitment Chain cũng được lưu trữ trong DA để đảm bảo khả năng xác minh và bảo mật bằng sự đồng thuận xã hội.
Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave) SCP tương tự như Sovereign Rollup, trong đó SCP cũng yêu cầu mã của ứng dụng được lưu vào DA. Trong Rooch, việc triển khai và nâng cấp hợp đồng là tất cả các giao dịch, và mã hợp đồng sẽ được ghi vào lớp DA trong 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 thời gian chạy của bất kỳ chuỗi nào dưới dạng môi trường thời gian chạy Move độc lập để xây dựng chuỗi ứng dụng hoặc chuỗi công khai mới.
Các dự án phi blockchain Các dự án phi blockchain có thể sử dụng MoveOS làm cơ sở dữ liệu với khả năng xác thực dữ liệu và khả năng chứng minh lưu trữ. Ví dụ: sử dụng nó để tạo một hệ thống blog cục bộ và cấu trúc dữ liệu và logic kinh doanh được thể hiện thông qua Move. Khi cơ sở hạ tầng trưởng thành 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 là nó có thể được sử dụng như một dịch vụ FaaS trong điện toán đám mây, nơi các nhà phát triển có thể viết các hàm trong FaaS thông qua Move, nền tảng lưu trữ trạng thái và các chức năng giữa người dùng cũng có thể được kết hợp và gọi bởi nhau. Có nhiều khả năng hơn để khám phá.
Cách tiếp cận mô-đun của Rooch có thể được điều chỉnh cho các loại và giai đoạn ứng dụng khác nhau. Ví dụ: các nhà phát triển trước tiên có thể xác minh ý tưởng của họ trên Rooch Ethereum Lớp 2 bằng cách triển khai các hợp đồng, sau đó di chuyển ứng dụng sang 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 sau khi chúng lớn lên.
Hoặc nhà phát triển có thể khởi chạy ứng dụng trực tiếp thông qua phương thức Sovereign Rollup, vì ứng dụng không có yêu cầu bảo mật cao trong giai đoạn đầu, và không cần trao đổi tài sản với các chuỗi khác, vì vậy nó có thể được xác minh trước. Khi các ứng dụng phát triển và có nhu cầu về tài sản kết nối với nhau, các yêu cầu bảo mật trở nên cao hơn và các mô-đun giải quyết và trọng tài có thể được kích hoạt để đảm bảo an toàn cho tài sản.
Xu hướng công nghệ cho các ứng dụng mô-đun
Tiềm năng của lớp DA vẫn chưa được khai thác
Như bạn có thể thấy từ phân tích trước, DA được dựa vào bất kể sự kết hợp. DA đóng một vai trò tương tự trong các ứng dụng phi tập trung như một nền tảng ghi nhật ký cho các hệ thống Web2, có thể được sử dụng để kiểm toán, phân tích dữ liệu lớn, đào tạo AI, v.v. Sẽ có rất 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, 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 Sequencer phải là một phần của DA và nếu lớp DA có thể cung cấp khả năng xác minh giao dịch cho ứng dụng và có đủ hiệu suất, trên thực tế, DA có thể đảm nhận trách nhiệm của Sequencer và người dùng ghi các giao dịch trực tiếp vào DA. Tất nhiên, liệu bạn có thể sử dụng token của ứng dụng để trả phí gas của DA hay không là một vấn đề khác cần được giải quyết.
Ngôn ngữ lập trình DApp sẽ bùng nổ
Các hình thức ứng dụng mới sẽ dẫn đến sự bùng nổ của các ngôn ngữ lập trình mới, điều đã được chứng minh trong kỷ nguyên Web2. Move sẽ là ngôn ngữ tốt nhất để xây dựng Web3 DApps. Ngoài bản chất ngôn ngữ của chính Move, còn có những lý do sau:
DApps 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 trong cùng một ngôn ngữ, tạo thành hiệu ứng tích tụ sinh thái. Vì vậy, hỗ trợ nhiều ngôn ngữ không phải là một chiến lược tốt lúc đầu.
Ít nhất, các ứng dụng phi tập trung cần phải có thể kiểm chứng được và các ngôn ngữ hợp đồng thông minh có thể giảm rất nhiều gánh nặng tinh thần cho các nhà phát triển về mặt đảm bảo khả năng xác minh.
Bản chất bất khả tri nền tảng của 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 di chuyển được cấu trúc, tạo điều kiện cho việc thể hiện cấu trúc dữ liệu của DApp cũng như truy xuất lưu trữ.
Tóm tắt
Tôi tham gia vào blockchain vào cuối năm 17 khi có rất nhiều nhóm trong ngành đang cố gắng xây dựng các ứng dụng trong không gian blockchain. Thật không may, cơ sở hạ tầng vẫn chưa hoàn thiện và ngành công nghiệp vẫn chưa tìm ra một mô hình có thể nhân rộng để xây dựng các ứng dụng và hầu hết các dự án ứng dụng đã kết thúc trong thất bại, ảnh hưởng đến các nhà phát triển và nhà đầu tư. Một ứng dụng nên được xây dựng trên blockchain như thế nào? Câu hỏi này đã suy nghĩ về tôi trong năm 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 đang dần trở nên rõ ràng hơn.
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ự hạ cánh.
