Giải thích kỹ thuật: Chuỗi Merlin hoạt động như thế nào?

Tác giả gốc: Faust, đam mê web3

Từ Summer of Inscription năm 2023 đến nay, Bitcoin Layer 2 luôn là điểm nhấn của toàn bộ Web3. Mặc dù sự phát triển của lĩnh vực này muộn hơn nhiều so với Ethereum Lớp 2, nhưng với sức hấp dẫn độc đáo của POW và việc triển khai suôn sẻ các quỹ ETF giao ngay, Bitcoin, vốn không cần lo lắng về rủi ro “chứng khoán hóa”, đã trở thành một Lớp Con đường phái sinh này đã thu hút được số vốn trị giá hàng chục tỷ USD chỉ trong nửa năm.

Trong đường đua Bitcoin Lớp 2, Merlin, với hàng tỷ đô la TVL, chắc chắn là người có khối lượng lớn nhất và nhiều người theo dõi nhất. Với những ưu đãi đặt cược rõ ràng và lợi nhuận đáng kể, Merlin gần như bất ngờ trỗi dậy từ mặt đất trong vòng vài tháng, tạo ra một huyền thoại sinh thái vượt qua Blast. Khi Merlin ngày càng trở nên phổ biến, các cuộc thảo luận về các giải pháp kỹ thuật của nó ngày càng trở thành chủ đề được nhiều người quan tâm.

Trong bài viết này, Geek Web3 sẽ tập trung vào giải pháp kỹ thuật Merlin Chain và diễn giải các tài liệu cũng như ý tưởng thiết kế giao thức đã xuất bản của nó . Chúng tôi cam kết giúp nhiều người hiểu hơn về quy trình làm việc chung của Merlin và hiểu rõ hơn về mô hình bảo mật của nó. cách "Head Bitcoin Layer 2" này hoạt động theo cách trực quan hơn.

Mạng oracle phi tập trung của Merlin: một ủy ban DAC ngoài chuỗi mở

Đối với tất cả Lớp 2, cho dù đó là Lớp 2 Ethereum hay Lớp 2 Bitcoin, DA và chi phí phát hành dữ liệu là một trong những vấn đề quan trọng nhất cần được giải quyết. Do bản thân mạng Bitcoin có nhiều vấn đề và không tự nhiên hỗ trợ thông lượng dữ liệu lớn, nên cách tận dụng không gian DA quý giá này đã trở thành một bài toán khó kiểm tra trí tưởng tượng của các dự án Lớp 2.

Một kết luận rất rõ ràng: nếu Lớp 2 "trực tiếp" xuất bản dữ liệu giao dịch chưa được xử lý vào khối Bitcoin, nó sẽ không đạt được thông lượng cao cũng như phí xử lý thấp. Các giải pháp phổ biến nhất là nén kích thước dữ liệu càng nhỏ càng tốt thông qua độ nén cao, sau đó tải nó lên khối Bitcoin hoặc xuất bản dữ liệu trực tiếp dưới chuỗi Bitcoin.

Trong số Lớp 2 áp dụng ý tưởng đầu tiên, ý tưởng nổi tiếng nhất có lẽ là Citrea. Họ dự định phân biệt các thay đổi trạng thái của Lớp 2 trong một khoảng thời gian (khác biệt trạng thái), tức là kết quả của các thay đổi trạng thái trên nhiều tài khoản, cùng với bằng chứng ZK tương ứng được tải lên chuỗi Bitcoin. Trong trường hợp này, bất kỳ ai cũng có thể tải xuống trạng thái khác biệt và ZKP từ mạng chính Bitcoin, sau đó theo dõi các thay đổi ở trạng thái Citrea. Phương pháp này có thể nén hơn 90% kích thước dữ liệu trên chuỗi.

Mặc dù điều này có thể nén kích thước dữ liệu rất nhiều nhưng nút cổ chai vẫn còn rõ ràng. Nếu một số lượng lớn tài khoản thay đổi trạng thái trong một khoảng thời gian ngắn, Lớp 2 phải tổng hợp và tải tất cả các thay đổi trong các tài khoản này lên chuỗi Bitcoin. Chi phí phát hành dữ liệu cuối cùng không thể được giữ ở mức rất thấp. Điều này đúng ở nhiều Ethereum. chuỗi. Điều này có thể được nhìn thấy trên ZK Rollup.

Nhiều Bitcoin Lớp 2 chỉ cần đi theo con đường thứ hai: sử dụng trực tiếp giải pháp DA ngoài chuỗi Bitcoin, tự xây dựng lớp DA hoặc sử dụng Celestia, EigenDA, v.v. B^Square, BitLayer và nhân vật chính của bài viết này, Merlin, đều sử dụng giải pháp mở rộng DA ngoài chuỗi này.

Trong bài viết trước của Geekweb3 - "Phân tích lộ trình kỹ thuật mới của B^ 2: Sự cần thiết của DA và lớp xác minh trong chuỗi Bitcoin", chúng tôi đã đề cập rằng B^ 2 bắt chước trực tiếp Celestia và xây dựng hỗ trợ ngoài chuỗi Mạng DA có chức năng lấy mẫu dữ liệu được đặt tên là B^2 Hub. "Dữ liệu DA" như dữ liệu giao dịch hoặc khác biệt trạng thái được lưu trữ trong chuỗi Bitcoin và chỉ gốc datahash / merkle mới được tải lên mạng chính Bitcoin.

Về cơ bản, điều này coi Bitcoin như một bảng thông báo không đáng tin cậy: bất kỳ ai cũng có thể đọc datahash từ chuỗi Bitcoin. Sau khi lấy dữ liệu DA từ nhà cung cấp dữ liệu ngoài chuỗi, bạn có thể kiểm tra xem nó có tương ứng với datahash trên chuỗi hay không , tức là hash(data 1) == datahash 1? . Nếu có sự tương ứng giữa hai bên, điều đó có nghĩa là dữ liệu do nhà cung cấp dữ liệu ngoài chuỗi cung cấp cho bạn là chính xác.

Quá trình trên có thể đảm bảo rằng dữ liệu được cung cấp cho bạn bởi các nút ngoài chuỗi được liên kết với một số "manh mối" nhất định trên Lớp 1, ngăn lớp DA cung cấp dữ liệu sai lệch một cách có ác ý. Nhưng đây là một kịch bản xấu rất quan trọng: Giả sử nguồn dữ liệu là Sequencer không gửi dữ liệu tương ứng với datahash mà chỉ gửi datahash đến chuỗi Bitcoin mà cố tình giữ lại dữ liệu tương ứng để ngăn chặn bất kỳ ai từ việc đọc nó. Take, tôi nên làm gì vào lúc này?

Các tình huống tương tự bao gồm nhưng không giới hạn ở: chỉ phát hành ZK-Proof và StateRoot, nhưng không phát hành dữ liệu DA tương ứng (dữ liệu giao dịch hoặc khác biệt trạng thái). Mặc dù mọi người có thể xác minh ZKProof và xác nhận rằng quy trình tính toán từ Prev_Stateroot đến New_Stateroot là hợp lệ, nhưng Nhưng tôi không biết trạng thái của tài khoản nào đã thay đổi. Trong trường hợp này, mặc dù tài sản của người dùng được an toàn nhưng mọi người đều không thể chắc chắn về trạng thái thực tế của mạng. Họ không biết giao dịch nào đã được đóng gói trên chuỗi và trạng thái hợp đồng nào đã được cập nhật. Tại thời điểm này, Lớp. 2 về cơ bản tương đương với việc tắt máy.

Đây thực chất là " giữ lại dữ liệu ". Dankrad của Ethereum Foundation từng thảo luận ngắn gọn về một vấn đề tương tự trên Twitter vào tháng 8 năm 2023. Tất nhiên, anh ấy chủ yếu nhắm vào một thứ gọi là "DAC".

Nhiều Ethereum Lớp 2 áp dụng giải pháp DA ngoài chuỗi thường thiết lập một số nút có quyền đặc biệt để thành lập ủy ban, tên đầy đủ là Ủy ban sẵn sàng dữ liệu (DAC) . Ủy ban DAC này đóng vai trò là người bảo lãnh và tuyên bố với thế giới bên ngoài rằng Sequencer thực sự đã phát hành dữ liệu DA hoàn chỉnh (dữ liệu giao dịch hoặc khác biệt trạng thái) ngoài chuỗi. Sau đó, các nút DAC cùng nhau tạo ra nhiều chữ ký Miễn là đa chữ ký đáp ứng các yêu cầu về ngưỡng (chẳng hạn như 2/4), các hợp đồng có liên quan trên Lớp 1 sẽ vượt qua sự kiểm tra của ủy ban DAC một cách trung thực. phát hành dữ liệu ngoài chuỗi DA hoàn chỉnh.

Ủy ban DAC của Ethereum Lớp 2 về cơ bản tuân theo mô hình POA, chỉ cho phép một số nút đã trải qua KYC hoặc được chỉ định chính thức tham gia ủy ban DAC . Điều này làm cho DAC đồng nghĩa với "tập trung hóa" và "chuỗi liên minh". Ngoài ra, trong một số Ethereum Lớp 2 áp dụng chế độ DAC, trình sắp xếp thứ tự chỉ gửi dữ liệu DA đến các nút thành viên DAC và hầu như không bao giờ tải dữ liệu lên nơi khác. Bất kỳ ai muốn lấy dữ liệu DA đều phải xin phép ủy ban DAC. không có sự khác biệt cơ bản so với chuỗi liên minh.

Không còn nghi ngờ gì nữa, DAC nên được phân quyền. Lớp 2 không cần tải dữ liệu DA trực tiếp lên Lớp 1. Tuy nhiên, quyền truy cập của ủy ban DAC nên được mở ra với thế giới bên ngoài để ngăn chặn một số người thông đồng làm điều ác. . (Để thảo luận về những cảnh ác quỷ của DAC, vui lòng tham khảo nhận xét trước đây của Dankrad trên Twitter)

BlobStream do Celestia đề xuất trước đây về cơ bản sử dụng Celestia để thay thế DAC tập trung . Trình sắp xếp chuỗi Ethereum L2 có thể xuất bản dữ liệu DA lên chuỗi Celestia. Nếu 2/3 số nút Celestia ký hợp đồng với nó, Lớp sẽ được triển khai trên Ethereum 2. Hợp đồng độc quyền sẽ giả định. rằng trình sắp xếp đã phát hành một cách trung thực dữ liệu DA, điều này thực sự cho phép nút Celestia hoạt động như một người bảo lãnh. Xem xét rằng Celestia có hàng trăm nút Trình xác thực, chúng ta có thể nghĩ rằng DAC lớn này tương đối phi tập trung.

Giải pháp DA được Merlin áp dụng thực sự tương đối gần với BlobStream của Celestia, cả hai đều mở quyền truy cập vào DAC thông qua POS, khiến nó trở nên phi tập trung hơn. Bất kỳ ai đặt cược đủ tài sản đều có thể chạy nút DAC. Trong tài liệu của Merlin, nút DAC được đề cập ở trên được gọi là Oracle và tuyên bố rằng nó sẽ hỗ trợ các cam kết tài sản bằng BTC, MERL và thậm chí cả mã thông báo BRC-20 để thực hiện cơ chế cam kết linh hoạt và cũng hỗ trợ các cam kết proxy tương tự như Lido. (Thỏa thuận cam kết POS của nhà tiên tri về cơ bản là một trong những câu chuyện cốt lõi tiếp theo của Merlin và lãi suất cam kết được cung cấp tương đối cao)

Ở đây chúng tôi mô tả ngắn gọn quy trình làm việc của Merlin (hình bên dưới):

• Sau khi trình sắp xếp chuỗi nhận được một số lượng lớn yêu cầu giao dịch, nó sẽ tổng hợp chúng và tạo ra một lô dữ liệu (lô dữ liệu), được chuyển đến nút Prover và nút Oracle (DAC phi tập trung).

• Nút Prover của Merlin được phân cấp và sử dụng Prover của lumoz làm dịch vụ Dịch vụ. Sau khi nhận được nhiều lô dữ liệu, nhóm khai thác Prover sẽ tạo ra bằng chứng không có kiến thức tương ứng. Sau đó, ZKP sẽ được gửi đến nút Oracle để xác minh.

• Nút Oracle sẽ xác minh xem Bằng chứng ZK được gửi bởi nhóm khai thác ZK của Lmuoz có tương ứng với Lô dữ liệu được gửi bởi Trình sắp xếp chuỗi hay không. Nếu cả hai có thể khớp nhau và không chứa các lỗi khác, quá trình xác minh sẽ được thông qua. Trong quá trình này, các nút Oracle phi tập trung sẽ tạo ra nhiều chữ ký thông qua chữ ký ngưỡng và tuyên bố với thế giới bên ngoài rằng trình sắp xếp chuỗi đã gửi hoàn toàn dữ liệu DA và ZKP tương ứng là hợp lệ và đã vượt qua quá trình xác minh của các nút Oracle.

• Trình sắp xếp chuỗi thu thập kết quả đa chữ ký từ các nút Oracle Khi số lượng chữ ký đáp ứng yêu cầu về ngưỡng, thông tin chữ ký sẽ được gửi đến chuỗi Bitcoin, cùng với datahash của dữ liệu DA (lô dữ liệu) và được chuyển ra bên ngoài. thế giới để đọc và xác nhận.

Nút Oracle thực hiện xử lý đặc biệt trong quy trình tính toán xác minh ZK Proof, tạo ra cam kết Cam kết và gửi nó đến chuỗi Bitcoin, cho phép bất kỳ ai thách thức "cam kết". Quy trình ở đây về cơ bản giống như giao thức chống gian lận của bitVM. Nếu thử thách thành công, nút Oracle đưa ra Cam kết sẽ bị trừng phạt về mặt tài chính. Tất nhiên, dữ liệu mà Oracle muốn xuất bản lên chuỗi Bitcoin cũng bao gồm hàm băm của trạng thái Lớp 2 hiện tại - StateRoot, cũng như chính ZKP, phải được xuất bản lên chuỗi Bitcoin để bên ngoài phát hiện.

Có một số chi tiết cần được trình bày chi tiết ở đây Trước hết, lộ trình của Merlin đề cập rằng Oracle sẽ sao lưu dữ liệu DA lên Celestia trong tương lai. Bằng cách này, các nút của Oracle có thể loại bỏ dữ liệu lịch sử cục bộ một cách hợp lý mà không cần phải lưu giữ Dữ liệu. tại địa phương. Đồng thời, Cam kết do Mạng Oracle tạo ra thực sự là gốc của Cây Merkle. Việc tiết lộ gốc cho thế giới bên ngoài là không đủ. Điều này đòi hỏi phải công khai. Nền tảng DA của bên thứ ba. Nền tảng này có thể là Celestia hoặc EigenDA hoặc các lớp DA khác.

Phân tích mô hình bảo mật: Dịch vụ MPC của ZKRollup+Cobo lạc quan

Ở trên, chúng tôi đã mô tả ngắn gọn quy trình làm việc của Merlin và tôi tin rằng bạn đã nắm vững cấu trúc cơ bản của nó. Không khó để nhận thấy rằng Merlin, B^Square, BitLayer và Citrea về cơ bản tuân theo cùng một mô hình bảo mật—ZK-Rollup lạc quan.

Khi đọc từ này lần đầu tiên, nhiều người đam mê Ethereum có thể cảm thấy kỳ lạ "ZK-Rollup lạc quan" là gì? Theo cách hiểu của cộng đồng Ethereum, "mô hình lý thuyết" của ZK Rollup hoàn toàn dựa trên độ tin cậy của các tính toán mật mã và không yêu cầu đưa ra các giả định về độ tin cậy. Từ "lạc quan" giới thiệu chính xác giả định về độ tin cậy, có nghĩa là hầu hết mọi người. lúc này, hãy lạc quan rằng Rollup không có lỗi và đáng tin cậy. Sau khi xảy ra lỗi, toán tử Rollup có thể bị trừng phạt thông qua bằng chứng gian lận. Đây là nguồn gốc của cái tên Optimistic Rollup, còn được gọi là OP Rollup.

Đối với hệ sinh thái Ethereum dựa trên Rollup, ZK-Rollup lạc quan có thể hơi khó hiểu, nhưng nó hoàn toàn phù hợp với tình hình hiện tại của Bitcoin Lớp 2. Do những hạn chế về mặt kỹ thuật, chuỗi Bitcoin không thể xác minh hoàn toàn ZK Proof và chỉ có thể xác minh một bước nhất định của quy trình tính toán ZKP trong những trường hợp đặc biệt, chuỗi Bitcoin thực sự chỉ có thể hỗ trợ giao thức chống gian lận. chỉ ra rằng có lỗi trong một bước tính toán nhất định của ZKP trong quá trình xác minh ngoài chuỗi và bị thách thức thông qua bằng chứng gian lận. Tất nhiên, điều này không thể so sánh với ZK Rollup theo phong cách Ethereum, nhưng nó đã nằm trong tầm tay. của Bitcoin Lớp 2. Mô hình bảo mật đáng tin cậy và an toàn nhất.

Theo sơ đồ ZK-Rollup lạc quan ở trên, giả sử rằng có N người trong mạng Lớp 2 có quyền bắt đầu các thử thách, miễn là một trong N người thách thức là trung thực và đáng tin cậy, thì có thể phát hiện được lỗi và bắt đầu bằng chứng gian lận tại chuyển đổi trạng thái Lớp 2 bất cứ lúc nào đều an toàn. Tất nhiên, Optimistic Rollup, có mức độ hoàn thiện tương đối cao, cần đảm bảo rằng cầu rút tiền của nó cũng được bảo vệ bởi giao thức chống gian lận. Tuy nhiên, hầu như tất cả Bitcoin Lớp 2 hiện không thể đạt được tiền đề này và cần phải dựa vào đa giao thức. signature/MPC Vậy chọn giải pháp đa chữ ký/MPC như thế nào?

Merlin đã chọn dịch vụ MPC của Cobo cho giải pháp bắc cầu, áp dụng các biện pháp như cách ly ví nóng và ví lạnh. Các tài sản bắc cầu được Cobo và Merlin Chain cùng quản lý. Mọi hành vi rút tiền cần phải được những người tham gia MPC của Cobo và Merlin Chain cùng nhau xử lý. về cơ bản là thông qua Sự chứng thực tín dụng của tổ chức đảm bảo độ tin cậy của cầu rút tiền. Tất nhiên, đây chỉ là biện pháp tạm thời ở giai đoạn này. Khi dự án dần được cải thiện, cầu rút tiền có thể được thay thế bằng "cầu lạc quan" với giả định độ tin cậy 1/N bằng cách giới thiệu BitVM và giao thức chống gian lận. việc thực hiện điều này sẽ khó khăn hơn (hiện tại hầu hết tất cả các cầu nối Lớp 2 chính thức đều dựa vào đa chữ ký).

Nhìn chung, chúng ta có thể thấy rằng Merlin đã giới thiệu giải pháp lưu ký tài sản MPC dựa trên POS, ZK-Rollup lạc quan dựa trên BitVM và MPC dựa trên Cobo để giải quyết vấn đề DA bằng cách mở các quyền DAC bằng cách giới thiệu BitVM và các giao thức chống gian lận. bảo mật của quá trình chuyển đổi trạng thái; đảm bảo độ tin cậy của cầu rút tiền bằng cách giới thiệu dịch vụ MPC của nền tảng lưu ký tài sản nổi tiếng Cobo.

Giải pháp gửi ZKP xác minh hai bước dựa trên Lumoz

Trước đó chúng tôi đã sắp xếp mô hình bảo mật của Merlin và giới thiệu khái niệm ZK-rollup lạc quan. Trong lộ trình công nghệ của Merlin, Prover phi tập trung cũng được nhắc đến. Như chúng ta đã biết, Prover đóng vai trò cốt lõi trong kiến trúc ZK-Rollup. Nó chịu trách nhiệm tạo ZKProof cho lô do Sequencer phát hành. Tuy nhiên, quá trình tạo bằng chứng không có kiến thức rất tốn tài nguyên phần cứng và rất tốn kém. vấn đề gai góc.

Để tăng tốc độ tạo ra các bằng chứng ZK, việc song song hóa và phân chia các nhiệm vụ là thao tác cơ bản nhất . Cái gọi là song song hóa thực sự có nghĩa là chia nhiệm vụ tạo bằng chứng ZK thành các phần khác nhau, được hoàn thành bởi các Nhà cung cấp khác nhau. Cuối cùng, Bộ tổng hợp sẽ tổng hợp nhiều Bằng chứng thành một tổng thể.

Để tăng tốc quá trình tạo bằng chứng ZK, Merlin sẽ sử dụng Prover của Lumoz làm giải pháp dịch vụ , giải pháp này thực sự tập hợp một số lượng lớn thiết bị phần cứng để tạo thành nhóm khai thác, sau đó phân bổ các tác vụ tính toán cho các thiết bị khác nhau và phân bổ Ưu đãi tương ứng có phần giống với khai thác POW.

Trong giải pháp Prover phi tập trung này, có một loại kịch bản tấn công, thường được gọi là tấn công chạy trước: Giả sử rằng một công cụ tổng hợp, Aggregator, đã thiết lập ZKP và gửi ZKP ra với hy vọng nhận được phần thưởng. Sau khi những người tổng hợp khác nhìn thấy nội dung của ZKP, họ xuất bản nội dung tương tự trước anh ta, cho rằng anh ta đã tạo ra ZKP trước. Làm thế nào để giải quyết tình huống này?

Có lẽ giải pháp bản năng nhất mà mọi người nghĩ đến là gán mã số nhiệm vụ được chỉ định cho mỗi Người tổng hợp. Ví dụ: chỉ Người tổng hợp A mới có thể nhận nhiệm vụ 1, còn những người khác sẽ không nhận được phần thưởng ngay cả khi họ hoàn thành nhiệm vụ 1. Nhưng có một vấn đề với cách tiếp cận này, đó là nó không thể chống lại rủi ro một điểm. Nếu Bộ tổng hợp A gặp lỗi về hiệu suất hoặc bị ngắt kết nối, tác vụ 1 sẽ bị kẹt và không thể hoàn thành. Hơn nữa, phương pháp phân công nhiệm vụ cho một đơn vị duy nhất này không thể nâng cao hiệu quả sản xuất thông qua cơ chế khuyến khích cạnh tranh và không phải là một cách tiếp cận tốt.

Polygon zkEVM đã từng đề xuất một phương pháp có tên Bằng chứng về hiệu quả trong một blog , trong đó chỉ ra rằng nên sử dụng các phương tiện cạnh tranh để thúc đẩy cạnh tranh giữa các Nhà tổng hợp khác nhau và các ưu đãi phải được phân bổ trên cơ sở ai đến trước được phục vụ trước. đầu tiên -Proof có thể được thưởng khi gửi Bộ tổng hợp vào chuỗi. Tất nhiên, anh ấy không đề cập đến cách giải quyết vấn đề chạy trước MEV.

Lumoz áp dụng phương pháp gửi bằng chứng ZK xác minh hai bước. Sau khi Bộ tổng hợp tạo bằng chứng ZK, trước tiên nó không cần gửi nội dung hoàn chỉnh mà chỉ xuất bản hàm băm ZKP, nói cách khác, xuất bản hàm băm (ZKP+Aggregator). Địa chỉ). Bằng cách này, ngay cả khi những người khác nhìn thấy giá trị băm, họ cũng không biết nội dung ZKP tương ứng và không thể trực tiếp tiếp tục;

Nếu ai đó chỉ sao chép toàn bộ hàm băm và xuất bản nó trước thì không có ích gì, vì hàm băm chứa địa chỉ của một tập hợp cụ thể X. Ngay cả khi tập hợp A xuất bản hàm băm trước, khi hình ảnh ban đầu của hàm băm được tiết lộ, mọi người sẽ Xem địa chỉ tổng hợp có trong đó là X chứ không phải A.

Thông qua sơ đồ gửi ZKP xác minh hai bước này, Merlin (Lumoz) có thể giải quyết vấn đề đang tồn tại trong quy trình gửi ZKP, từ đó đạt được các khuyến khích tạo bằng chứng không có kiến thức có tính cạnh tranh cao, từ đó tăng tốc độ tạo ZKP.

Merlin's Phantom: Khả năng tương tác đa chuỗi

Theo lộ trình kỹ thuật của Merlin, chúng cũng sẽ hỗ trợ khả năng tương tác giữa Merlin và các chuỗi EVM khác . Lộ trình triển khai về cơ bản giống như ý tưởng Zetachain trước đây. Nếu Merlin được sử dụng làm chuỗi nguồn và các chuỗi EVM khác được sử dụng làm chuỗi mục tiêu. khi Merlin Sau khi nút cảm nhận được yêu cầu tương tác chuỗi chéo do người dùng đưa ra, nó sẽ kích hoạt quy trình làm việc tiếp theo trên chuỗi mục tiêu.

Ví dụ: tài khoản EOA do mạng Merlin kiểm soát có thể được triển khai trên Polygon. Khi người dùng đưa ra hướng dẫn về khả năng tương tác chuỗi chéo trên Chuỗi Merlin, mạng Merlin trước tiên sẽ phân tích nội dung của nó, tạo ra dữ liệu giao dịch để thực thi trên mục tiêu. chuỗi, sau đó Mạng Oracle thực hiện xử lý chữ ký MPC trên giao dịch và tạo chữ ký số của giao dịch. Sau đó, nút Relayer của Merlin sẽ giải phóng giao dịch trên Polygon và hoàn thành các hoạt động tiếp theo thông qua tài sản của Merlin trong tài khoản EOA trên chuỗi mục tiêu.

Khi hoạt động mà người dùng yêu cầu hoàn tất, tài sản tương ứng sẽ được chuyển tiếp trực tiếp đến địa chỉ của người dùng trên chuỗi mục tiêu. Về lý thuyết, nó cũng có thể được chuyển trực tiếp đến Chuỗi Merlin. Giải pháp này có một số lợi ích rõ ràng: nó có thể tránh được phí xử lý và hao mòn do các hợp đồng cầu nối chuỗi chéo gây ra khi tài sản truyền thống xuyên chuỗi và tính bảo mật của các hoạt động chuỗi chéo được đảm bảo trực tiếp bởi Mạng lưới Oracle của Merlin và có không cần phải dựa vào cơ sở hạ tầng bên ngoài. Miễn là người dùng tin tưởng Merlin Chain, hành vi tương tác chuỗi chéo như vậy có thể được coi là không có vấn đề gì.

Tóm tắt

Trong bài viết này, chúng tôi giải thích ngắn gọn về giải pháp kỹ thuật chung của Merlin Chain. Chúng tôi tin rằng giải pháp này có thể giúp nhiều người hiểu hơn về quy trình làm việc chung của Merlin và hiểu rõ hơn về mô hình bảo mật của nó. Xét rằng hệ sinh thái Bitcoin hiện tại đang phát triển mạnh mẽ, chúng tôi tin rằng loại hình phổ biến khoa học kỹ thuật này là có giá trị và cần thiết đối với công chúng. Chúng tôi sẽ tiến hành theo dõi lâu dài các dự án như Merlin, bitLayer và B^Square. trong tương lai , chúng tôi sẽ cung cấp phân tích sâu hơn về các giải pháp kỹ thuật, vì vậy hãy chú ý theo dõi!