Tác giả: Lisa A., Taiko Labs; biên dịch: Jinse Finance xiaozou
Bài viết này sẽ thảo luận về các phương thức nhắn tin chuỗi chéo L2 khác nhau từ góc độ tổng số, tập trung vào giao tiếp chuỗi chéo mà không cần sự tin tưởng. Chúng ta sẽ xem xét ngắn gọn cách tiếp cận đọc trạng thái trực tiếp, cách tiếp cận máy khách nhẹ và bằng chứng lưu trữ. Chúng tôi cũng sẽ đề cập đến cơ chế tổng hợp bằng chứng, truyền thông báo xuyên chuỗi đáng tin cậy của bên thứ ba và các giải pháp chuỗi chéo ZK cốt lõi. Cuối cùng, ngày nay chúng ta hãy xem các L2 khác nhau thực hiện nhắn tin chuỗi chéo như thế nào.
1. Giới thiệu về nhắn tin chuỗi chéo
Đối với giao tiếp xuyên chuỗi, tất cả các bên (L2, L3, v.v.) phải có quyền truy cập trực tiếp vào gốc trạng thái Ethereum mới nhất.
Tất cả các lớp ký gửi đều có cơ chế chuỗi chéo "tích hợp sẵn" có thể được sử dụng để truy cập gốc trạng thái L1, cơ chế này sẽ được chuyển đến L2 dưới dạng thông báo ký gửi.
1**.1** Hai loại quyền truy cập vào trạng thái gốc
Loại 1: Đọc trạng thái gốc trực tiếp - có thể được thực hiện thông qua opcode hoặc biên dịch sẵn. Tuy nhiên, đến nay vẫn chưa thực hiện nên không cần chứng minh.
Brecht Devos mô tả một phương pháp khả thi để đọc trực tiếp trạng thái trong một bài báo nghiên cứu: “…chúng ta có thể đưa ra một hợp đồng được biên dịch sẵn có thể gọi trực tiếp một hợp đồng thông minh trên chuỗi mục tiêu. Hợp đồng được biên dịch trước này trực tiếp trong Chuỗi nguồn sẽ chèn và thực thi mã hợp đồng thông minh của một chuỗi khác .Điều này đảm bảo rằng các hợp đồng thông minh luôn có quyền truy cập vào trạng thái mới nhất hiện có một cách hiệu quả và dễ dàng chứng minh.”
· Cũng được mô tả trong RFP của Optimism "Bằng chứng khái niệm yêu cầu tĩnh từ xa".
Loại 2: Tạo bằng chứng - tức là chứng minh một tuyên bố về một chuỗi khối trên một chuỗi khối khác.
"Nhắn chuỗi chéo có bằng chứng" có hai cách tiếp cận:
· Giao tiếp xuyên chuỗi không đáng tin cậy — nghĩa là không có bên thứ ba đáng tin cậy (ví dụ: sử dụng ứng dụng khách nhẹ hoặc bằng chứng lưu trữ). Cách tiếp cận không tin cậy có thể được sử dụng cho cả việc tạo bằng chứng của bên thứ ba và cho những người tham gia giao tiếp xuyên chuỗi để tự tạo bằng chứng.
Bằng chứng được chia sẻ giữa các bản tổng hợp khác nhau để đảm bảo hoạt động xuyên chuỗi. Cách tiếp cận này, không được thảo luận nhiều trong bài viết này, hiện đang trong giai đoạn nghiên cứu và thăm dò và không được coi là một giải pháp có khả năng áp dụng rộng rãi.
1**.2** Phương pháp “Nhắn tin xuyên chuỗi có bằng chứng”
1.2.1Nhắn tin liên chuỗi khách hàng nhẹ
Chứng minh dữ liệu trên chuỗi B
Lấy dữ liệu bằng chứng Merkle từ nút đầy đủ của chuỗi B (nút lưu trữ lưu trữ nếu cần bằng chứng lưu trữ cho các trạng thái lịch sử nhất định);
Gửi tiêu đề khối và dữ liệu bằng chứng tương ứng với khối chuỗi B chứa trạng thái mà chúng tôi muốn xác minh tới hợp đồng chứng minh trên chuỗi A dưới dạng calldata;
Hợp đồng chứng minh tính toán giá trị băm khối dựa trên dữ liệu tiêu đề khối, truy vấn hợp đồng thông minh của ứng dụng khách nhẹ trên chuỗi A (theo dõi giá trị băm khối của chuỗi B) và kiểm tra xem giá trị băm có hợp lệ hay không;
Dữ liệu bằng chứng được xác minh đối với gốc trạng thái byte32 trong tiêu đề khối.
1**.2.2** Bằng chứng lưu trữ
Proof of Storage có hai tùy chọn "quy trình làm việc":
· Tạo bằng chứng lưu trữ → sử dụng trên chuỗi
· Tạo bằng chứng lưu trữ → tạo bằng chứng zk → sử dụng trên chuỗi
Một thực thể cũng có thể đóng gói nhiều bộ sưu tập bằng chứng thành một bằng chứng duy nhất (cả bằng chứng về lưu trữ và bằng chứng về zk). Đây là một bước tối ưu hóa tùy chọn và chưa được thảo luận.
Chúng ta hãy xem ba giai đoạn chính của "quy trình" bằng chứng lưu trữ: tạo bằng chứng lưu trữ, tạo bằng chứng zk và sử dụng nó trên chuỗi.
(1) Tạo bằng chứng lưu trữ
· Bằng chứng lưu trữ cho phép chúng tôi sử dụng một cam kết bí mật để chứng minh rằng một số thông tin nhất định tồn tại trên chuỗi khối và là sự thật;
Bằng chứng lưu trữ đã là một phần của không gian tiền điện tử kể từ khi cây Merkle ra đời vào năm 1979. Tuy nhiên, bằng chứng lưu trữ vani thường khá lớn. Sự đổi mới hiện đại nằm ở việc kết hợp bằng chứng lưu trữ với tính toán có thể chứng minh được để tạo ra bằng chứng ngắn gọn có thể được xác minh trên chuỗi.
Để tạo Bằng chứng lưu trữ, bạn phải cung cấp một khối dữ liệu cụ thể và đường dẫn Merkle hoặc Verkle được liên kết trong cây Merkle. Đường dẫn bao gồm các giá trị băm anh chị em cần thiết để xây dựng lại hàm băm gốc bằng cách sử dụng cùng một thuật toán băm.
Để xác minh Bằng chứng lưu trữ, người nhận có thể sử dụng dữ liệu được cung cấp và đường dẫn Merkle hoặc Verkle để tính toán lại hàm băm gốc. Nếu hàm băm gốc được tính toán lại khớp với hàm băm gốc đã biết, thì người nhận có thể tin tưởng rằng dữ liệu là xác thực và là một phần của tập dữ liệu đã gửi.
(2) Tạo ZKP (Bằng chứng không kiến thức)
Tuy nhiên, Bằng chứng lưu trữ kiểu Ethereum có kích thước khoảng 4kb - khá lớn để đăng toàn bộ Bằng chứng lưu trữ trên chuỗi mục tiêu, vì việc xác minh bằng chứng sẽ rất tốn kém. Do đó, việc sử dụng ZKP (ví dụ: ZK-SNARK) để nén là hợp lý, điều này có thể làm cho bằng chứng nhỏ hơn và rẻ hơn để xác minh.
（3）A **** lănZKP
Sau khi kiếm được ZKP, người dùng trên chuỗi mục tiêu có thể hủy kiểm soát bằng chứng kiếm được của họ (ví dụ: truy cập trạng thái lịch sử thông qua tiêu đề khối hoặc băm khối).
Bỏ cuộn có thể được thực hiện như sau:
Tích lũy trên chuỗi: Toàn bộ quá trình tái tạo lại tiêu đề khối từ bằng chứng được thực hiện trực tiếp trên chuỗi khối. Nhược điểm: phí gas cao, tiêu tốn tài nguyên máy tính; ưu điểm: không có thời gian chứng minh bổ sung, độ trễ thấp vì không cần tạo bằng chứng bên ngoài chuỗi khối.
Nén trên chuỗi: Xóa thông tin dư thừa hoặc không cần thiết khỏi dữ liệu hoặc sử dụng cấu trúc dữ liệu được tối ưu hóa để tiết kiệm không gian. Dữ liệu nén được gửi đến chuỗi khối và có thể được giải nén khi cần. Nhược điểm: Nén và giải nén dữ liệu có thể có nghĩa là tính toán bổ sung, nhưng độ trễ này có thể không đáng kể. Thuật toán nén được sử dụng có thể có tác động tiêu cực đến tính bảo mật của dữ liệu; ưu điểm: giảm chi phí dữ liệu.
Lưu trữ ngoài chuỗi: Lưu trữ dữ liệu ngoài chuỗi và đưa các khối dữ liệu cụ thể vào chuỗi theo yêu cầu. Điều này phù hợp với các giải pháp cần lưu trữ lượng lớn dữ liệu vì một số lý do (ví dụ: các nút lưu trữ Ethereum từ khối genesis). Nhược điểm: Giống như nén trên chuỗi; Ưu điểm: Giảm thêm chi phí dữ liệu.
1**.2.3** Bên thứ ba đáng tin cậy
Một giải pháp chuỗi chéo hoàn chỉnh cũng phải bao gồm các giải pháp nhắn tin chéo với các bên thứ ba đáng tin cậy (chẳng hạn như oracle, cầu tập trung, v.v.).
1**.2.4** Hệ thống Bằng chứng “Phổ quát”
Trong trường hợp cơ chế nền tảng bằng chứng tổng hợp được chia sẻ, việc nhắn tin có thể được tăng tốc bằng cách nhận các hàm băm khối được giải quyết trong nền tảng tổng hợp và việc dàn xếp ở đây cũng sẽ xử lý việc nhắn tin (nhưng nếu có vấn đề với nền tảng tổng hợp phải làm gì?).
1**.2.5 Một số vấn đề chưa biết về ZK****thông điệp liên chuỗi**
Việc nhắn tin xuyên chuỗi có khả thi mà không có bên thứ ba đáng tin cậy (có thể là một thực thể hoặc nhiều thực thể) không? Cơ chế hiệu quả để truyền thông điệp xuyên chuỗi là gì? Nói chung, đối với Ethereum L2 (có quyền truy cập trực tiếp vào các khối băm của L1) và chính Ethereum, nếu một chuỗi có thể chạy ứng dụng khách nhẹ, v.v., thì điều đó là đủ để nhắn tin xuyên chuỗi không tin cậy.
Mạch ZK được sử dụng để tạo bằng chứng chuỗi chéo có được chia tỷ lệ đúng không? Trong một số trường hợp, đặc biệt là khi lớp đồng thuận (cần được xác minh cho các hoạt động xuyên chuỗi) rất lớn, mạch được sử dụng để truyền thông điệp chuỗi chéo ZK có thể lớn hơn các đơn đặt hàng so với tổng số và lưu trữ trên chuỗi, và chi phí tính toán cũng rất lớn. Có lẽ vấn đề này có thể được khắc phục bằng cách tiếp cận tập trung hơn.
2**、Ví dụ về giải pháp nhắn tin xuyên chuỗi**
· Su****ccinct Labs sử dụng ứng dụng khách nhẹ để xác minh sự đồng thuận từ chuỗi nguồn đến lớp đồng thuận chuỗi đích. Ý tưởng là tồn tại một giao thức máy khách nhẹ để đảm bảo rằng các nút có thể đồng bộ hóa các tiêu đề khối của trạng thái chuỗi khối cuối cùng. ZKP được sử dụng để tạo bằng chứng đồng thuận.
· La****grange Labs xây dựng bằng chứng trạng thái chuỗi chéo không tương tác. Lagrange chứng minh rằng mạng chịu trách nhiệm tạo gốc trạng thái. Mỗi nút Lagrange chứa một phần khóa riêng của phân đoạn, khóa này chứng thực trạng thái của một chuỗi cụ thể. Mỗi gốc trạng thái là một gốc Verkle có chữ ký ngưỡng có thể được sử dụng để chứng thực trạng thái của một chuỗi cụ thể tại một thời điểm cụ thể. Gốc trạng thái là hoàn toàn chung chung và có thể được sử dụng trong bằng chứng trạng thái để chứng minh trạng thái hiện tại của bất kỳ hợp đồng hoặc ví nào trong chuỗi.
· He****rodotus sử dụng bằng chứng lưu trữ ZKP để cung cấp hợp đồng thông minh và truy cập dữ liệu trên chuỗi các lớp Ethereum khác một cách đồng bộ. Để xác thực, nó sử dụng tin nhắn L1<>L2 gốc để đồng bộ hóa các hàm băm khối giữa các lần cuộn Ethereum.
=nil; Foundation (Mina, L1) cho phép các hợp đồng thông minh trên Ethereum xác minh tính hợp lệ của trạng thái Mina. Tạo bằng chứng trạng thái có mục đích đặc biệt, giá rẻ để xác minh trên Ethereum (bằng chứng Mina cục bộ trên Ethereum rất đắt). Theo giả thuyết (đôi khi trong tương lai), các ứng dụng có thể trực tiếp sử dụng công cụ tạo bằng chứng của Mina để kiểm tra tính hợp lệ của các giao dịch xuyên chuỗi. =nil; Foundation cũng có Thị trường bằng chứng nơi người dùng/dự án chủ yếu có thể mua/bán bằng chứng SNARK cho phép truy cập dữ liệu không đáng tin cậy.
Axiom: Nếu Axiom đã tạo ZKP cho sổ cái cho đến nay - nó không cần tạo ZKP cho một khối cụ thể - nó có thể chuyển ZKP này tới chuỗi (dưới dạng người chuyển tiếp) hoặc thậm chí Cung cấp quyền truy cập vào ZKP này.
3. Nhắn tin liên chuỗi L2
Tuyên bố miễn trừ trách nhiệm: Nhắn tin xuyên chuỗi vẫn đang phát triển cho hầu hết L2. Tất cả các phân tích dưới đây dựa trên thông tin nguồn mở. Điều đó nói rằng, các giải pháp được đề cập trong bài viết có thể đang ở giai đoạn khám phá và thử nghiệm, và quá trình tổng hợp cuối cùng có thể áp dụng các phương pháp khác. *
**（1）**Taiko
Taiko lưu trữ khối băm cho mỗi chuỗi. Đối với mỗi cặp chuỗi, nó triển khai hai hợp đồng thông minh lưu trữ các giá trị băm của nhau. Trong ví dụ về L2←→L1, mỗi khi một khối L2 được tạo trên Taiko, giá trị băm của các khối ngoại vi trên L1 được lưu trữ trong hợp đồng TaikoL2. Ngoài ra, trong trường hợp L1←→L2, chế độ hoạt động cũng giống như vậy.
Có thể lấy gốc Merkle đã biết mới nhất được lưu trữ trên chuỗi mục tiêu bằng cách gọi getCrossChainBlockHash(0) trên hợp đồng TaikoL1/TaikoL2 và nhận giá trị/thông báo để xác minh. Có thể thu được hàm băm anh chị em của gốc Merkle đã biết mới nhất bằng cách gọi yêu cầu eth_getProof bằng cách sử dụng RPC tiêu chuẩn trên "chuỗi nguồn".
Sau đó, chỉ cần gửi chúng để được xác minh dựa trên các hàm băm khối đã biết mới nhất được lưu trữ trong danh sách trên "chuỗi mục tiêu". Trình xác thực sẽ lấy một giá trị (một lá trên cây Merkle) và các giá trị băm anh chị em để tính toán lại gốc Merkle và kiểm tra xem giá trị đó có khớp với gốc được lưu trữ trong danh sách băm khối của chuỗi mục tiêu hay không.
**（2）**Starknet
Starknet sử dụng Proof of Storage để gửi tin nhắn xuyên chuỗi không đáng tin cậy.
L2→Giao thức nhắn tin L1
· Trong quá trình thực hiện giao dịch Starknet, hợp đồng trên Starknet sẽ gửi thông báo L2→L1.
Các tham số bản tin (chứa hợp đồng người nhận và dữ liệu liên quan trên L1) sau đó được thêm vào bản cập nhật trạng thái có liên quan (cây lưu trữ chính).
· Tin nhắn L2 được lưu trữ trên L1 của hợp đồng thông minh.
· Phát hành một sự kiện trên L1 (lưu trữ thông số tin nhắn).
Địa chỉ người nhận trên L1 có thể truy cập và sử dụng tin nhắn như một phần của giao dịch L1 bằng cách cung cấp lại các tham số tin nhắn.
· Thông báo chuỗi chéo được lưu trữ trong cây thân cây.
L2 → L1
L1 → L2
**（3）**Lạc quan
Giao tiếp giữa L1 và L2 được thực hiện bởi hai hợp đồng thông minh đặc biệt được gọi là "sứ giả".
· Đối với các giao dịch Optimism (L2) sang Ethereum (L1), cần cung cấp bằng chứng Merkle về thông báo trên L1 sau khi gốc trạng thái được viết. Sau khi giao dịch bằng chứng này trở thành một phần của chuỗi L1, giai đoạn thử thách lỗi bắt đầu. Sau khoảng thời gian chờ đợi này, bất kỳ người dùng nào cũng có thể "hoàn tất" giao dịch bằng cách kích hoạt giao dịch thứ hai trên Ethereum, gửi tin nhắn đến hợp đồng L1 mục tiêu.
· Thông báo chuỗi chéo được lưu trữ trong cây thân cây.
（4）Ar****bitrum
Vé có thể thử lại là phương pháp chính tắc mà Arbitrum sử dụng để tạo thông báo từ L1 đến L2, tức là các giao dịch L1 khởi tạo thông báo sẽ được thực thi trên L2. Một Retryable có thể được gửi trên L1 với một khoản phí cố định (chỉ phụ thuộc vào kích thước calldata của nó). Cây trạng thái chính được sử dụng để liên lạc xuyên chuỗi các định dạng dữ liệu tùy chỉnh trong hợp đồng thông minh. Việc gửi một vé có thể thử lại trên L1 có thể tách rời/không đồng bộ với việc thực thi trên L2. Retryables cung cấp tính nguyên tử giữa các hoạt động xuyên chuỗi. Nếu yêu cầu giao dịch L1 được gửi thành công (tức là không có khôi phục), thì việc thực thi Có thể thử lại trên L2 có một sự đảm bảo chắc chắn rằng cuối cùng nó sẽ thành công.
Arbitrum có hai thân: Chuỗi Nitro được duy trì ở định dạng cây trạng thái của Ethereum, cây Merkle. Cây xác nhận lưu trữ trạng thái của chuỗi Arbitrum được xác nhận trên Ethereum thông qua "xác nhận". Các quy tắc thúc đẩy chuỗi Arbitrum mang tính quyết định. Điều này có nghĩa là với trạng thái của chuỗi và một số giá trị đầu vào mới, chỉ có một đầu ra hợp lệ. Do đó, nếu cây chứng minh chứa nhiều lá, thì nhiều nhất một lá có thể biểu thị trạng thái chuỗi hợp lệ.
Hệ thống Hộp thư đi của Arbitrum cho phép mọi lệnh gọi hợp đồng từ L2 đến L1, tức là một thông báo được bắt đầu từ L2 và cuối cùng được thực hiện trên L1. Tin nhắn L2 đến L1 (còn gọi là "tin nhắn gửi đi") có nhiều điểm chung với tin nhắn L1 đến L2 của Arbitrum (Có thể thử lại), mặc dù có một số khác biệt đáng chú ý. Một phần của trạng thái L2 của chuỗi Arbitrum—nghĩa là phần được chứng thực trong mỗi RBlock—là gốc Merkle của tất cả các thông báo từ L2 đến L1 trong lịch sử của chuỗi. Sau khi RBlock đã được chứng minh được xác nhận (thường là khoảng một tuần sau khi có bằng chứng), gốc Merkle được bao gồm trong hợp đồng Hộp thư đi và được xuất bản lên L1. Hợp đồng Hộp thư đi sau đó cho phép người dùng thực hiện tin nhắn của họ.
**（5）**Đa giác zkEVM
· Cầu SC của zkEVM này sử dụng cây Merkle đặc biệt có tên là Cây thoát cho mỗi mạng tham gia giao dịch liên lạc hoặc tài sản.
Nó sử dụng gốc Merkle (trong một cây trạng thái riêng), sơ đồ kiến trúc cầu có thể được tìm thấy trên github.
Việc triển khai zkEVM Bridge SC đã thực hiện một số thay đổi dựa trên hợp đồng tiền gửi Ethereum 2.0. Ví dụ: nó sử dụng cây Merkle chỉ nối thêm được thiết kế đặc biệt, nhưng sử dụng logic tương tự như hợp đồng tiền gửi Ethereum 2.0. Những khác biệt khác liên quan đến giá trị băm cơ sở và nút lá.
Tính năng chính của hợp đồng thông minh Polygon zkEVM Bridge là việc sử dụng Cây thoát và Cây thoát toàn cầu, trong đó gốc của Cây thoát toàn cầu là nguồn chính của trạng thái sự thật. Do đó, L1 và L2 có hai trình quản lý gốc thoát toàn cầu khác nhau và Bridge SC có một logic riêng biệt.
（6）S****cuộn
· Hợp đồng cầu nối được triển khai trên Ethereum và Scroll cho phép người dùng chuyển thông báo tùy ý giữa L1 và L2. Ngoài giao thức nhắn tin này, chúng tôi cũng đã xây dựng một giao thức bắc cầu không đáng tin cậy để cho phép người dùng kết nối tài sản ERC-20 giữa L1 và L2. Để gửi tin nhắn hoặc tiền từ Ethereum đến Scroll, người dùng gọi giao dịch sendMessage trên hợp đồng Bridge. Người chuyển tiếp sẽ lập chỉ mục giao dịch này trên L1 và gửi nó cho người đặt hàng để đưa vào khối L2. Trên hợp đồng cầu nối L2, quá trình gửi tin nhắn từ Scroll back đến Ethereum cũng tương tự.
· Tin nhắn xuyên chuỗi được lưu trữ trong hàng đợi tin nhắn thông thường. Người đặt hàng nhập các thông báo xuyên chuỗi từ hàng đợi này và thêm chúng vào chuỗi như các giao dịch thông thường.
**（7）**Kỷ nguyên zksync
*Tuyên bố miễn trừ trách nhiệm: Nội dung trong phần này chỉ nói về Kỷ nguyên zksync, có thể khác với thông báo xuyên chuỗi trên ZK Stack, đây là một khung mô-đun để xây dựng siêu chuỗi ZK có chủ quyền. *
· Mỗi gói giao dịch có một bản tin L2->L1.
· Không thể gửi giao dịch trực tiếp từ L2 đến L1. Tuy nhiên, bạn có thể gửi tin nhắn có độ dài bất kỳ từ Kỷ nguyên zkSync đến Ethereum, sau đó xử lý tin nhắn nhận được trên Ethereum bằng hợp đồng thông minh L1. zkSync Era có chức năng chứng minh yêu cầu sẽ trả về tham số boolean cho biết liệu tin nhắn có được gửi thành công tới L1 hay không. Truy xuất bằng chứng Merkle có trong thông báo bằng cách quan sát Ethereum hoặc sử dụng phương thức zks_getL2ToL1LogProof của API zksync-web3.
· Đối với L1→L2, hợp đồng thông minh Kỷ nguyên zkSync cho phép người gửi yêu cầu giao dịch trên Ethereum L1 và chuyển dữ liệu tới zkSync Kỷ nguyên L2.
· Hợp đồng cầu nối:
4. Kết luận
Giao tiếp xuyên chuỗi là không thể thiếu đối với các ứng dụng "phải có" để áp dụng hàng loạt chuỗi khối (ví dụ: ví phục hồi xã hội chuỗi chéo được mô tả trong bài viết Vitalik). Hầu hết các giải pháp chuỗi chéo hiện đang được sử dụng đều được thiết kế cho L1←→L2 để bao hàm chức năng rút tiền. Các giải pháp này có thể được mở rộng cho nhiều chuỗi khối hơn. Nhưng đồng thời, các giải pháp giao tiếp xuyên chuỗi tiên tiến hơn có thể được triển khai, chẳng hạn như "trạng thái đọc trực tiếp" mà không cần bằng chứng hoặc "bằng chứng lưu trữ" mà không cần tin cậy. Đối với hầu hết các L2, vẫn còn chỗ để cải thiện giao tiếp xuyên chuỗi.
Xem bản gốc
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Khám phá giao tiếp xuyên chuỗi từ góc độ tổng số
Tác giả: Lisa A., Taiko Labs; biên dịch: Jinse Finance xiaozou
Bài viết này sẽ thảo luận về các phương thức nhắn tin chuỗi chéo L2 khác nhau từ góc độ tổng số, tập trung vào giao tiếp chuỗi chéo mà không cần sự tin tưởng. Chúng ta sẽ xem xét ngắn gọn cách tiếp cận đọc trạng thái trực tiếp, cách tiếp cận máy khách nhẹ và bằng chứng lưu trữ. Chúng tôi cũng sẽ đề cập đến cơ chế tổng hợp bằng chứng, truyền thông báo xuyên chuỗi đáng tin cậy của bên thứ ba và các giải pháp chuỗi chéo ZK cốt lõi. Cuối cùng, ngày nay chúng ta hãy xem các L2 khác nhau thực hiện nhắn tin chuỗi chéo như thế nào.
1. Giới thiệu về nhắn tin chuỗi chéo
Đối với giao tiếp xuyên chuỗi, tất cả các bên (L2, L3, v.v.) phải có quyền truy cập trực tiếp vào gốc trạng thái Ethereum mới nhất.
Tất cả các lớp ký gửi đều có cơ chế chuỗi chéo "tích hợp sẵn" có thể được sử dụng để truy cập gốc trạng thái L1, cơ chế này sẽ được chuyển đến L2 dưới dạng thông báo ký gửi.
1**.1** Hai loại quyền truy cập vào trạng thái gốc
Loại 1: Đọc trạng thái gốc trực tiếp - có thể được thực hiện thông qua opcode hoặc biên dịch sẵn. Tuy nhiên, đến nay vẫn chưa thực hiện nên không cần chứng minh.
Brecht Devos mô tả một phương pháp khả thi để đọc trực tiếp trạng thái trong một bài báo nghiên cứu: “…chúng ta có thể đưa ra một hợp đồng được biên dịch sẵn có thể gọi trực tiếp một hợp đồng thông minh trên chuỗi mục tiêu. Hợp đồng được biên dịch trước này trực tiếp trong Chuỗi nguồn sẽ chèn và thực thi mã hợp đồng thông minh của một chuỗi khác .Điều này đảm bảo rằng các hợp đồng thông minh luôn có quyền truy cập vào trạng thái mới nhất hiện có một cách hiệu quả và dễ dàng chứng minh.”
· Cũng được mô tả trong RFP của Optimism "Bằng chứng khái niệm yêu cầu tĩnh từ xa".
Loại 2: Tạo bằng chứng - tức là chứng minh một tuyên bố về một chuỗi khối trên một chuỗi khối khác.
"Nhắn chuỗi chéo có bằng chứng" có hai cách tiếp cận:
· Giao tiếp xuyên chuỗi không đáng tin cậy — nghĩa là không có bên thứ ba đáng tin cậy (ví dụ: sử dụng ứng dụng khách nhẹ hoặc bằng chứng lưu trữ). Cách tiếp cận không tin cậy có thể được sử dụng cho cả việc tạo bằng chứng của bên thứ ba và cho những người tham gia giao tiếp xuyên chuỗi để tự tạo bằng chứng.
Bằng chứng được chia sẻ giữa các bản tổng hợp khác nhau để đảm bảo hoạt động xuyên chuỗi. Cách tiếp cận này, không được thảo luận nhiều trong bài viết này, hiện đang trong giai đoạn nghiên cứu và thăm dò và không được coi là một giải pháp có khả năng áp dụng rộng rãi.
1**.2** Phương pháp “Nhắn tin xuyên chuỗi có bằng chứng”
1.2.1 Nhắn tin liên chuỗi khách hàng nhẹ
Chứng minh dữ liệu trên chuỗi B
Lấy dữ liệu bằng chứng Merkle từ nút đầy đủ của chuỗi B (nút lưu trữ lưu trữ nếu cần bằng chứng lưu trữ cho các trạng thái lịch sử nhất định);
Gửi tiêu đề khối và dữ liệu bằng chứng tương ứng với khối chuỗi B chứa trạng thái mà chúng tôi muốn xác minh tới hợp đồng chứng minh trên chuỗi A dưới dạng calldata;
Hợp đồng chứng minh tính toán giá trị băm khối dựa trên dữ liệu tiêu đề khối, truy vấn hợp đồng thông minh của ứng dụng khách nhẹ trên chuỗi A (theo dõi giá trị băm khối của chuỗi B) và kiểm tra xem giá trị băm có hợp lệ hay không;
Dữ liệu bằng chứng được xác minh đối với gốc trạng thái byte32 trong tiêu đề khối.
1**.2.2** Bằng chứng lưu trữ
Proof of Storage có hai tùy chọn "quy trình làm việc":
· Tạo bằng chứng lưu trữ → sử dụng trên chuỗi
· Tạo bằng chứng lưu trữ → tạo bằng chứng zk → sử dụng trên chuỗi
Một thực thể cũng có thể đóng gói nhiều bộ sưu tập bằng chứng thành một bằng chứng duy nhất (cả bằng chứng về lưu trữ và bằng chứng về zk). Đây là một bước tối ưu hóa tùy chọn và chưa được thảo luận.
Chúng ta hãy xem ba giai đoạn chính của "quy trình" bằng chứng lưu trữ: tạo bằng chứng lưu trữ, tạo bằng chứng zk và sử dụng nó trên chuỗi.
(1) Tạo bằng chứng lưu trữ
· Bằng chứng lưu trữ cho phép chúng tôi sử dụng một cam kết bí mật để chứng minh rằng một số thông tin nhất định tồn tại trên chuỗi khối và là sự thật;
Bằng chứng lưu trữ đã là một phần của không gian tiền điện tử kể từ khi cây Merkle ra đời vào năm 1979. Tuy nhiên, bằng chứng lưu trữ vani thường khá lớn. Sự đổi mới hiện đại nằm ở việc kết hợp bằng chứng lưu trữ với tính toán có thể chứng minh được để tạo ra bằng chứng ngắn gọn có thể được xác minh trên chuỗi.
Để tạo Bằng chứng lưu trữ, bạn phải cung cấp một khối dữ liệu cụ thể và đường dẫn Merkle hoặc Verkle được liên kết trong cây Merkle. Đường dẫn bao gồm các giá trị băm anh chị em cần thiết để xây dựng lại hàm băm gốc bằng cách sử dụng cùng một thuật toán băm.
Để xác minh Bằng chứng lưu trữ, người nhận có thể sử dụng dữ liệu được cung cấp và đường dẫn Merkle hoặc Verkle để tính toán lại hàm băm gốc. Nếu hàm băm gốc được tính toán lại khớp với hàm băm gốc đã biết, thì người nhận có thể tin tưởng rằng dữ liệu là xác thực và là một phần của tập dữ liệu đã gửi.
(2) Tạo ZKP (Bằng chứng không kiến thức)
Tuy nhiên, Bằng chứng lưu trữ kiểu Ethereum có kích thước khoảng 4kb - khá lớn để đăng toàn bộ Bằng chứng lưu trữ trên chuỗi mục tiêu, vì việc xác minh bằng chứng sẽ rất tốn kém. Do đó, việc sử dụng ZKP (ví dụ: ZK-SNARK) để nén là hợp lý, điều này có thể làm cho bằng chứng nhỏ hơn và rẻ hơn để xác minh.
（3）A **** lăn ZKP
Sau khi kiếm được ZKP, người dùng trên chuỗi mục tiêu có thể hủy kiểm soát bằng chứng kiếm được của họ (ví dụ: truy cập trạng thái lịch sử thông qua tiêu đề khối hoặc băm khối).
Bỏ cuộn có thể được thực hiện như sau:
Tích lũy trên chuỗi: Toàn bộ quá trình tái tạo lại tiêu đề khối từ bằng chứng được thực hiện trực tiếp trên chuỗi khối. Nhược điểm: phí gas cao, tiêu tốn tài nguyên máy tính; ưu điểm: không có thời gian chứng minh bổ sung, độ trễ thấp vì không cần tạo bằng chứng bên ngoài chuỗi khối.
Nén trên chuỗi: Xóa thông tin dư thừa hoặc không cần thiết khỏi dữ liệu hoặc sử dụng cấu trúc dữ liệu được tối ưu hóa để tiết kiệm không gian. Dữ liệu nén được gửi đến chuỗi khối và có thể được giải nén khi cần. Nhược điểm: Nén và giải nén dữ liệu có thể có nghĩa là tính toán bổ sung, nhưng độ trễ này có thể không đáng kể. Thuật toán nén được sử dụng có thể có tác động tiêu cực đến tính bảo mật của dữ liệu; ưu điểm: giảm chi phí dữ liệu.
Lưu trữ ngoài chuỗi: Lưu trữ dữ liệu ngoài chuỗi và đưa các khối dữ liệu cụ thể vào chuỗi theo yêu cầu. Điều này phù hợp với các giải pháp cần lưu trữ lượng lớn dữ liệu vì một số lý do (ví dụ: các nút lưu trữ Ethereum từ khối genesis). Nhược điểm: Giống như nén trên chuỗi; Ưu điểm: Giảm thêm chi phí dữ liệu.
1**.2.3** Bên thứ ba đáng tin cậy
Một giải pháp chuỗi chéo hoàn chỉnh cũng phải bao gồm các giải pháp nhắn tin chéo với các bên thứ ba đáng tin cậy (chẳng hạn như oracle, cầu tập trung, v.v.).
1**.2.4** Hệ thống Bằng chứng “Phổ quát”
Trong trường hợp cơ chế nền tảng bằng chứng tổng hợp được chia sẻ, việc nhắn tin có thể được tăng tốc bằng cách nhận các hàm băm khối được giải quyết trong nền tảng tổng hợp và việc dàn xếp ở đây cũng sẽ xử lý việc nhắn tin (nhưng nếu có vấn đề với nền tảng tổng hợp phải làm gì?).
1**.2.5 Một số vấn đề chưa biết về ZK****thông điệp liên chuỗi**
Việc nhắn tin xuyên chuỗi có khả thi mà không có bên thứ ba đáng tin cậy (có thể là một thực thể hoặc nhiều thực thể) không? Cơ chế hiệu quả để truyền thông điệp xuyên chuỗi là gì? Nói chung, đối với Ethereum L2 (có quyền truy cập trực tiếp vào các khối băm của L1) và chính Ethereum, nếu một chuỗi có thể chạy ứng dụng khách nhẹ, v.v., thì điều đó là đủ để nhắn tin xuyên chuỗi không tin cậy.
Mạch ZK được sử dụng để tạo bằng chứng chuỗi chéo có được chia tỷ lệ đúng không? Trong một số trường hợp, đặc biệt là khi lớp đồng thuận (cần được xác minh cho các hoạt động xuyên chuỗi) rất lớn, mạch được sử dụng để truyền thông điệp chuỗi chéo ZK có thể lớn hơn các đơn đặt hàng so với tổng số và lưu trữ trên chuỗi, và chi phí tính toán cũng rất lớn. Có lẽ vấn đề này có thể được khắc phục bằng cách tiếp cận tập trung hơn.
2**、Ví dụ về giải pháp nhắn tin xuyên chuỗi**
· Su****ccinct Labs sử dụng ứng dụng khách nhẹ để xác minh sự đồng thuận từ chuỗi nguồn đến lớp đồng thuận chuỗi đích. Ý tưởng là tồn tại một giao thức máy khách nhẹ để đảm bảo rằng các nút có thể đồng bộ hóa các tiêu đề khối của trạng thái chuỗi khối cuối cùng. ZKP được sử dụng để tạo bằng chứng đồng thuận.
· La****grange Labs xây dựng bằng chứng trạng thái chuỗi chéo không tương tác. Lagrange chứng minh rằng mạng chịu trách nhiệm tạo gốc trạng thái. Mỗi nút Lagrange chứa một phần khóa riêng của phân đoạn, khóa này chứng thực trạng thái của một chuỗi cụ thể. Mỗi gốc trạng thái là một gốc Verkle có chữ ký ngưỡng có thể được sử dụng để chứng thực trạng thái của một chuỗi cụ thể tại một thời điểm cụ thể. Gốc trạng thái là hoàn toàn chung chung và có thể được sử dụng trong bằng chứng trạng thái để chứng minh trạng thái hiện tại của bất kỳ hợp đồng hoặc ví nào trong chuỗi.
· He****rodotus sử dụng bằng chứng lưu trữ ZKP để cung cấp hợp đồng thông minh và truy cập dữ liệu trên chuỗi các lớp Ethereum khác một cách đồng bộ. Để xác thực, nó sử dụng tin nhắn L1<>L2 gốc để đồng bộ hóa các hàm băm khối giữa các lần cuộn Ethereum.
=nil; Foundation (Mina, L1) cho phép các hợp đồng thông minh trên Ethereum xác minh tính hợp lệ của trạng thái Mina. Tạo bằng chứng trạng thái có mục đích đặc biệt, giá rẻ để xác minh trên Ethereum (bằng chứng Mina cục bộ trên Ethereum rất đắt). Theo giả thuyết (đôi khi trong tương lai), các ứng dụng có thể trực tiếp sử dụng công cụ tạo bằng chứng của Mina để kiểm tra tính hợp lệ của các giao dịch xuyên chuỗi. =nil; Foundation cũng có Thị trường bằng chứng nơi người dùng/dự án chủ yếu có thể mua/bán bằng chứng SNARK cho phép truy cập dữ liệu không đáng tin cậy.
Axiom: Nếu Axiom đã tạo ZKP cho sổ cái cho đến nay - nó không cần tạo ZKP cho một khối cụ thể - nó có thể chuyển ZKP này tới chuỗi (dưới dạng người chuyển tiếp) hoặc thậm chí Cung cấp quyền truy cập vào ZKP này.
3. Nhắn tin liên chuỗi L2
**（1）**Taiko
Taiko lưu trữ khối băm cho mỗi chuỗi. Đối với mỗi cặp chuỗi, nó triển khai hai hợp đồng thông minh lưu trữ các giá trị băm của nhau. Trong ví dụ về L2←→L1, mỗi khi một khối L2 được tạo trên Taiko, giá trị băm của các khối ngoại vi trên L1 được lưu trữ trong hợp đồng TaikoL2. Ngoài ra, trong trường hợp L1←→L2, chế độ hoạt động cũng giống như vậy.
Có thể lấy gốc Merkle đã biết mới nhất được lưu trữ trên chuỗi mục tiêu bằng cách gọi getCrossChainBlockHash(0) trên hợp đồng TaikoL1/TaikoL2 và nhận giá trị/thông báo để xác minh. Có thể thu được hàm băm anh chị em của gốc Merkle đã biết mới nhất bằng cách gọi yêu cầu eth_getProof bằng cách sử dụng RPC tiêu chuẩn trên "chuỗi nguồn".
Sau đó, chỉ cần gửi chúng để được xác minh dựa trên các hàm băm khối đã biết mới nhất được lưu trữ trong danh sách trên "chuỗi mục tiêu". Trình xác thực sẽ lấy một giá trị (một lá trên cây Merkle) và các giá trị băm anh chị em để tính toán lại gốc Merkle và kiểm tra xem giá trị đó có khớp với gốc được lưu trữ trong danh sách băm khối của chuỗi mục tiêu hay không.
**（2）**Starknet
Starknet sử dụng Proof of Storage để gửi tin nhắn xuyên chuỗi không đáng tin cậy.
L2→Giao thức nhắn tin L1
· Trong quá trình thực hiện giao dịch Starknet, hợp đồng trên Starknet sẽ gửi thông báo L2→L1.
Các tham số bản tin (chứa hợp đồng người nhận và dữ liệu liên quan trên L1) sau đó được thêm vào bản cập nhật trạng thái có liên quan (cây lưu trữ chính).
· Tin nhắn L2 được lưu trữ trên L1 của hợp đồng thông minh.
· Phát hành một sự kiện trên L1 (lưu trữ thông số tin nhắn).
Địa chỉ người nhận trên L1 có thể truy cập và sử dụng tin nhắn như một phần của giao dịch L1 bằng cách cung cấp lại các tham số tin nhắn.
· Thông báo chuỗi chéo được lưu trữ trong cây thân cây.
L2 → L1
L1 → L2
**（3）**Lạc quan
Giao tiếp giữa L1 và L2 được thực hiện bởi hai hợp đồng thông minh đặc biệt được gọi là "sứ giả".
· Đối với các giao dịch Optimism (L2) sang Ethereum (L1), cần cung cấp bằng chứng Merkle về thông báo trên L1 sau khi gốc trạng thái được viết. Sau khi giao dịch bằng chứng này trở thành một phần của chuỗi L1, giai đoạn thử thách lỗi bắt đầu. Sau khoảng thời gian chờ đợi này, bất kỳ người dùng nào cũng có thể "hoàn tất" giao dịch bằng cách kích hoạt giao dịch thứ hai trên Ethereum, gửi tin nhắn đến hợp đồng L1 mục tiêu.
· Thông báo chuỗi chéo được lưu trữ trong cây thân cây.
（4）Ar****bitrum
Vé có thể thử lại là phương pháp chính tắc mà Arbitrum sử dụng để tạo thông báo từ L1 đến L2, tức là các giao dịch L1 khởi tạo thông báo sẽ được thực thi trên L2. Một Retryable có thể được gửi trên L1 với một khoản phí cố định (chỉ phụ thuộc vào kích thước calldata của nó). Cây trạng thái chính được sử dụng để liên lạc xuyên chuỗi các định dạng dữ liệu tùy chỉnh trong hợp đồng thông minh. Việc gửi một vé có thể thử lại trên L1 có thể tách rời/không đồng bộ với việc thực thi trên L2. Retryables cung cấp tính nguyên tử giữa các hoạt động xuyên chuỗi. Nếu yêu cầu giao dịch L1 được gửi thành công (tức là không có khôi phục), thì việc thực thi Có thể thử lại trên L2 có một sự đảm bảo chắc chắn rằng cuối cùng nó sẽ thành công.
Arbitrum có hai thân: Chuỗi Nitro được duy trì ở định dạng cây trạng thái của Ethereum, cây Merkle. Cây xác nhận lưu trữ trạng thái của chuỗi Arbitrum được xác nhận trên Ethereum thông qua "xác nhận". Các quy tắc thúc đẩy chuỗi Arbitrum mang tính quyết định. Điều này có nghĩa là với trạng thái của chuỗi và một số giá trị đầu vào mới, chỉ có một đầu ra hợp lệ. Do đó, nếu cây chứng minh chứa nhiều lá, thì nhiều nhất một lá có thể biểu thị trạng thái chuỗi hợp lệ.
Hệ thống Hộp thư đi của Arbitrum cho phép mọi lệnh gọi hợp đồng từ L2 đến L1, tức là một thông báo được bắt đầu từ L2 và cuối cùng được thực hiện trên L1. Tin nhắn L2 đến L1 (còn gọi là "tin nhắn gửi đi") có nhiều điểm chung với tin nhắn L1 đến L2 của Arbitrum (Có thể thử lại), mặc dù có một số khác biệt đáng chú ý. Một phần của trạng thái L2 của chuỗi Arbitrum—nghĩa là phần được chứng thực trong mỗi RBlock—là gốc Merkle của tất cả các thông báo từ L2 đến L1 trong lịch sử của chuỗi. Sau khi RBlock đã được chứng minh được xác nhận (thường là khoảng một tuần sau khi có bằng chứng), gốc Merkle được bao gồm trong hợp đồng Hộp thư đi và được xuất bản lên L1. Hợp đồng Hộp thư đi sau đó cho phép người dùng thực hiện tin nhắn của họ.
**（5）**Đa giác zkEVM
· Cầu SC của zkEVM này sử dụng cây Merkle đặc biệt có tên là Cây thoát cho mỗi mạng tham gia giao dịch liên lạc hoặc tài sản.
Nó sử dụng gốc Merkle (trong một cây trạng thái riêng), sơ đồ kiến trúc cầu có thể được tìm thấy trên github.
Việc triển khai zkEVM Bridge SC đã thực hiện một số thay đổi dựa trên hợp đồng tiền gửi Ethereum 2.0. Ví dụ: nó sử dụng cây Merkle chỉ nối thêm được thiết kế đặc biệt, nhưng sử dụng logic tương tự như hợp đồng tiền gửi Ethereum 2.0. Những khác biệt khác liên quan đến giá trị băm cơ sở và nút lá.
Tính năng chính của hợp đồng thông minh Polygon zkEVM Bridge là việc sử dụng Cây thoát và Cây thoát toàn cầu, trong đó gốc của Cây thoát toàn cầu là nguồn chính của trạng thái sự thật. Do đó, L1 và L2 có hai trình quản lý gốc thoát toàn cầu khác nhau và Bridge SC có một logic riêng biệt.
（6）S****cuộn
· Hợp đồng cầu nối được triển khai trên Ethereum và Scroll cho phép người dùng chuyển thông báo tùy ý giữa L1 và L2. Ngoài giao thức nhắn tin này, chúng tôi cũng đã xây dựng một giao thức bắc cầu không đáng tin cậy để cho phép người dùng kết nối tài sản ERC-20 giữa L1 và L2. Để gửi tin nhắn hoặc tiền từ Ethereum đến Scroll, người dùng gọi giao dịch sendMessage trên hợp đồng Bridge. Người chuyển tiếp sẽ lập chỉ mục giao dịch này trên L1 và gửi nó cho người đặt hàng để đưa vào khối L2. Trên hợp đồng cầu nối L2, quá trình gửi tin nhắn từ Scroll back đến Ethereum cũng tương tự.
· Tin nhắn xuyên chuỗi được lưu trữ trong hàng đợi tin nhắn thông thường. Người đặt hàng nhập các thông báo xuyên chuỗi từ hàng đợi này và thêm chúng vào chuỗi như các giao dịch thông thường.
**（7）**Kỷ nguyên zksync
*Tuyên bố miễn trừ trách nhiệm: Nội dung trong phần này chỉ nói về Kỷ nguyên zksync, có thể khác với thông báo xuyên chuỗi trên ZK Stack, đây là một khung mô-đun để xây dựng siêu chuỗi ZK có chủ quyền. *
· Mỗi gói giao dịch có một bản tin L2->L1.
· Không thể gửi giao dịch trực tiếp từ L2 đến L1. Tuy nhiên, bạn có thể gửi tin nhắn có độ dài bất kỳ từ Kỷ nguyên zkSync đến Ethereum, sau đó xử lý tin nhắn nhận được trên Ethereum bằng hợp đồng thông minh L1. zkSync Era có chức năng chứng minh yêu cầu sẽ trả về tham số boolean cho biết liệu tin nhắn có được gửi thành công tới L1 hay không. Truy xuất bằng chứng Merkle có trong thông báo bằng cách quan sát Ethereum hoặc sử dụng phương thức zks_getL2ToL1LogProof của API zksync-web3.
· Đối với L1→L2, hợp đồng thông minh Kỷ nguyên zkSync cho phép người gửi yêu cầu giao dịch trên Ethereum L1 và chuyển dữ liệu tới zkSync Kỷ nguyên L2.
· Hợp đồng cầu nối:
4. Kết luận
Giao tiếp xuyên chuỗi là không thể thiếu đối với các ứng dụng "phải có" để áp dụng hàng loạt chuỗi khối (ví dụ: ví phục hồi xã hội chuỗi chéo được mô tả trong bài viết Vitalik). Hầu hết các giải pháp chuỗi chéo hiện đang được sử dụng đều được thiết kế cho L1←→L2 để bao hàm chức năng rút tiền. Các giải pháp này có thể được mở rộng cho nhiều chuỗi khối hơn. Nhưng đồng thời, các giải pháp giao tiếp xuyên chuỗi tiên tiến hơn có thể được triển khai, chẳng hạn như "trạng thái đọc trực tiếp" mà không cần bằng chứng hoặc "bằng chứng lưu trữ" mà không cần tin cậy. Đối với hầu hết các L2, vẫn còn chỗ để cải thiện giao tiếp xuyên chuỗi.