Kể từ "Mùa hè khắc chữ" vào năm 2023, các công nghệ Layer2 của Bitcoin đã đi đầu trong cuộc cách mạng Web3. Mặc dù tham gia vào lĩnh vực này muộn hơn các giải pháp Layer2 của Ethereum, Bitcoin đã tận dụng sức hấp dẫn độc đáo của POW và sự ra mắt trơn tru của các ETF giao ngay, không có rủi ro "chứng khoán hóa", để thu hút hàng tỷ đô la đầu tư vào lĩnh vực đang phát triển này chỉ trong vòng sáu tháng. Trong số này, Merlin nổi bật là thực thể đáng kể và được theo dõi nhiều nhất trong bối cảnh Bitcoin Layer2, chỉ huy hàng tỷ tổng giá trị bị khóa (TVL). Nhờ các ưu đãi đặt cọc rõ ràng và lợi nhuận ấn tượng, Merlin nhanh chóng nổi lên, vượt qua cả hệ sinh thái Blast nổi tiếng chỉ trong vài tháng. Với tiếng vang ngày càng tăng xung quanh Merlin, việc khám phá cơ sở hạ tầng kỹ thuật của nó đã thu hút ngày càng nhiều khán giả. Trong bài viết này, Geek Web3 tập trung vào việc giải mã các chiến lược kỹ thuật đằng sau Merlin Chain. Bằng cách giải nén các tài liệu có sẵn công khai và lý do đằng sau thiết kế giao thức của nó, chúng tôi mong muốn làm sáng tỏ các quy trình hoạt động của Merlin và nâng cao hiểu biết về khung bảo mật của nó, cung cấp cái nhìn rõ ràng hơn về cách thức hoạt động của giải pháp Bitcoin Layer2 hàng đầu này.

Mạng Oracle Phi Tập Trung Của Merlin: Một Ủy Ban DAC Off-Chain Mở

Đối với mỗi công nghệ Layer2, việc giải quyết sẵn dữ liệu (DA) và chi phí xuất bản dữ liệu vẫn là một thách thức quan trọng, cho dù đó là cho Ethereum Layer2 hay Bitcoin Layer2. Với những hạn chế bẩm sinh của mạng Bitcoin, mà gặp khó khăn với lưu lượng dữ liệu lớn, việc lên chiến lược sử dụng hiệu quả không gian DA quý giá là một bài kiểm tra quan trọng đối với sự sáng tạo của các nhà phát triển Layer2.

Rõ ràng rằng nếu các dự án Layer2 muốn trực tiếp xuất bản dữ liệu giao dịch gốc lên blockchain Bitcoin, họ sẽ không thể đạt được cả hiệu suất cao và phí thấp. Các giải pháp chiếm ưu thế bao gồm việc nén dữ liệu mạnh để giảm kích thước một cách đáng kể trước khi tải lên blockchain Bitcoin, hoặc lựa chọn xuất bản dữ liệu ngoài chuỗi.

Trong số những người áp dụng chiến lược đầu tiên, Citrea nổi bật. Họ nhằm tải lên các thay đổi trong các trạng thái Layer2 qua các khoảng thời gian cụ thể, bao gồm việc ghi lại 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 các chứng minh không biết (ZKPs) tương ứng, lên chuỗi khối Bitcoin. Dưới sự sắp xếp này, bất kỳ ai cũng có thể truy cập các thay đổi trạng thái và ZKPs từ mạng chính Bitcoin để theo dõi các thay đổi trạng thái của Citrea. Phương pháp này hiệu quả giảm kích thước dữ liệu được tải lên chuỗi khối lên đến hơn 90%.

Mặc dù điều này có thể nén kích thước dữ liệu một cách lớn, nhưng bottleneck vẫn rõ ràng. Nếu một số lượng lớn tài khoản thay đổi trạng thái của họ trong một khoảng thời gian ngắn, Layer 2 phải tổng hợp và tải lên tất cả các thay đổi trong những 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ữ rất thấp. Điều này đúng trong nhiều Ethereum. Điều này có thể thấy trong ZK Rollup.

Nhiều Bitcoin Layer 2 đơn giản chỉ đi theo con đường thứ hai: trực tiếp sử dụng giải pháp DA dưới chuỗi Bitcoin, hoặc xây dựng một lớp DA bằng chính họ, 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 off-chain này.

Bài viết trước trong geek web3——“Phân tích B^2 New Version Technology Roadmap: Sự cần thiết của DA và Lớp Xác minh dưới Chuỗi Bitcoin”, chúng tôi đã đề cập rằng B^2 trực tiếp bắt chước Celestia và xây dựng mạng lưới DA hỗ trợ chức năng lấy mẫu dữ liệu dưới chuỗi, được gọi là B^2 Hub. Dữ liệu DA như dữ liệu giao dịch hoặc trạng thái khác nhau được lưu trữ dưới chuỗi Bitcoin, và chỉ có datahash / merkle root được tải lên mạng lưới Bitcoin chính.

Điều này về cơ bản coi Bitcoin như một bảng tin không tin cậy: bất kỳ ai cũng có thể đọc datahash từ chuỗi Bitcoin. Sau khi bạn nhận được 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ó tương ứng với datahash trên chuỗi on-chain, tức là hash(data1) == datahash1? Nếu có sự tương ứng giữa hai bên, điều đó có nghĩa là dữ liệu mà nhà cung cấp dữ liệu ngoại chuỗi đưa cho bạn là chính xác.

Lớp DA trong Layer2 của Bitcoin được giải thích:

(Nguồn Ảnh: Geek web3)

Hệ thống này đảm bảo rằng dữ liệu từ các nút ngoại chuỗi tương quan với các “dấu vết” hoặc bằng chứng cụ thể trên Layer1, bảo vệ chống lại vấn đề tiềm ẩn của lớp DA cung cấp thông tin sai lệch. Tuy nhiên, một lo ngại quan trọng nảy sinh nếu người tạo ra dữ liệu - Sequencer - không phân phối dữ liệu thực sự liên quan đến một datahash. Giả sử Sequencer chỉ truyền tải datahash đến blockchain Bitcoin trong khi cố ý giữ lại dữ liệu tương ứng không cho quyền truy cập công cộng. Khi đó sẽ xảy ra điều gì?

Xem xét các kịch bản trong đó chỉ ZK-Proof và StateRoot được công khai, nhưng dữ liệu DA đi kèm (như state diffs hoặc dữ liệu giao dịch) không được phát hành. Mặc dù có thể xác thực ZK-Proof và đảm bảo rằng sự chuyển đổi từ Prev_Stateroot sang New_Stateroot là chính xác, nhưng không biết tài khoản nào đã thay đổi trạng thái. Dưới những hoàn cảnh này, mặc dù tài sản của người dùng vẫn an toàn, tình trạng thực tế của mạng vẫn không rõ ràng. Không ai biết giao dịch nào đã được tích hợp vào blockchain hoặc trạng thái hợp đồng nào đã được cập nhật, khiến cho Layer2 trở nên không hoạt động, gần như như nó đã bị ngừng hoạt động.

Thực hành này được gọi là “data withholding.” Vào tháng 8 năm 2023, Dankrad từ Ethereum Foundation đã khởi xướng một cuộc thảo luận trên Twitter về một khái niệm được biết đến là “DAC.”

Trong nhiều thiết lập Ethereum Layer2 sử dụng các giải pháp khả dụng dữ liệu (DA) ngoại tuyến, thường có một số nút với đặc quyền đặc biệt tạo thành một ủy ban được biết đến là ủy ban sẵn sàng dữ liệu (DAC). Ủy ban này phục vụ như một người bảo lãnh, đảm bảo 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 sự khác biệt trạng thái) ngoại tuyến. Các thành viên DAC sau đó tạo một chữ ký đa chữ ký. Nếu chữ ký đa chữ ký này đạt được ngưỡng yêu cầu (ví dụ, 2 trên 4), các hợp đồng tương ứng trên Layer1 được thiết kế để giả định rằng Sequencer đã đáp ứng các tiêu chuẩn xác minh của DAC và đã thực sự phát hành dữ liệu DA đầy đủ ngoại tuyến.

Các ủy ban DAC của Ethereum Layer2 chủ yếu tuân theo mô hình Proof of Authority (POA), giới hạn thành viên chỉ cho một nhóm chọn lọc các nút đã vượt qua KYC hoặc đã được chính thức chỉ định. Phương pháp này đã hiệu quả đánh dấu DAC như là điển hình của “tính trung tâm” và “blockchain hợp tác.” Ngoài ra, trong một số Ethereum Layer2 sử dụng phương pháp DAC, người sắp xếp phân phối dữ liệu DA chỉ cho các nút thành viên DAC, với sự phổ biến bên ngoài tối thiểu. Do đó, bất kỳ ai cần dữ liệu DA phải đảm bảo được sự chấp thuận từ DAC, tương tự như hoạt động trong một blockchain hợp tác.

Rõ ràng rằng DACs cần phải phân quyền. Mặc dù Layer2 có thể không cần thiết để tải dữ liệu DA trực tiếp lên Layer1, quyền truy cập thành viên của DAC nên được công khai để tránh sự kết hợp và hành vi bất chính của một số cá nhân. (Để biết thêm thông tin về vấn đề này, hãy tham khảo các cuộc thảo luận trước đó của Dankrad trên Twitter.)

Đề xuất của Celestia về BlobStream về cơ bản nhằm thay thế một DAC tập trung bằng Celestia. Theo mô hình này, một sequencer Ethereum L2 sẽ đăng dữ liệu DA lên blockchain của Celestia. Nếu hai phần ba số node của Celestia xác nhận dữ liệu này, hợp đồng Layer2 chuyên biệt trên Ethereum sẽ xác nhận rằng sequencer đã xuất bản dữ liệu DA một cách chính xác, từ đó đặt node Celestia như người bảo đảm. Với việc Celestia hoạt động với hàng trăm node xác nhận, cấu hình DAC lớn hơn này được coi là tương đối phi tập trung.

Giải pháp DA được Merlin áp dụng thực sự khá gần với BlobStream của Celestia, cả hai đều mở cửa truy cập vào DAC thông qua POS, khiến nó trở nên phân quyền hơn. Bất kỳ ai cũng có thể vận hành một nút DAC miễn là họ đặt cược đủ tài sản. Trong tài liệu của Merlin, nút DAC được đề cập ở trên được gọi là Oracle, và được chỉ ra rằng nó sẽ hỗ trợ cam kết tài sản của BTC, MERL và thậm chí cả cá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ợ cam kết ủy quyền tương tự như Lido. (Thỏa thuận cam kết POS của máy báo cáo 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 khá cao)

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

1. Sau khi bộ xử lý 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), sau đó chuyển cho nút Prover và nút Oracle (DAC phi tập trung).

2. Nút chứng minh của Merlin là phi tập trung và sử dụng dịch vụ Chứng minh của Prover của lumoz. Sau khi nhận được nhiều loạt dữ liệu, hồ bơi đào tạo Prover sẽ tạo ra các chứng minh không thông tin tương ứng. Sau đó, ZKP sẽ được gửi đến nút Oracle để xác minh.

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

4. Bộ xếp hạng thu thập kết quả đa chữ ký từ các nút Oracle. Khi số lượng chữ ký đạt đến yêu cầu ngưỡng, thông tin chữ ký được gửi đến chuỗi Bitcoin, cùng với datahash của dữ liệu DA (bộ dữ liệu), và được giao cho thế giới bên ngoài để đọc và xác nhận.

(Sơ đồ nguyên lý hoạt động của Merlin: Geek web3)

1. Các nút Oracle thực hiện xử lý đặc biệt trên quá trình tính toán để xác minh ZK Proof, tạo ra cam kết Commitment, và gửi chúng đến chuỗi Bitcoin, cho phép bất kỳ ai cũng có thể thách thức 'cam kết'.Quá trình ở đây về cơ bản cũng giống như giao thức chứng cớ gian lận của bitVM. Nếu thách thức thành công, nút Oracle đã phát hành Commitment sẽ bị phạ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 băm của trạng thái Layer 2 hiện tại - StateRoot, cũng như ZKP chính nó, cần được xuất bản lên chuỗi Bitcoin để phát hiện bên ngoài.

Tham khảo:“Một Phần Diễn Giải Tối Giản về BitVM: Làm thế nào để Xác minh Bằng chứng Lừa đảo trên Chuỗi BTC”

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

Tham khảo:“Phân tích B^2 New Version Technology Roadmap: Sự cần thiết của DA và Lớp Xác minh dưới Chuỗi Bitcoin”

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

Ở trên, chúng tôi đã tóm tắt ngắn gọn về quy trình làm việc của Merlin, và tôi tin rằng bạn đã thành thạo 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 cơ bản tuân theo cùng một mô hình bảo mật - Optimistic ZK-Rollup.

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

Đối với hệ sinh thái Ethereum tại cơ sở của Rollup, ZK-Rollup lạc quan có thể hơi mơ hồ, nhưng nó chính xác phù hợp với tình hình hiện tại của Bitcoin Layer 2. Do hạn chế kỹ thuật, chuỗi Bitcoin không thể hoàn toàn xác minh ZK Proof. Nó chỉ có thể xác minh một bước nhất định của quá trình tính toán của ZKP trong các trường hợp đặc biệt. Dưới tiền đề này, chuỗi Bitcoin thực sự chỉ có thể hỗ trợ giao thức chứng minh gian lận. Mọi người có thể 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à thách thức thông qua chứng minh gian lận. Tất nhiên, điều này không thể so sánh với ZK Rollup kiểu Ethereum, nhưng đó là điều tốt nhất mà Bitcoin Layer 2 hiện đã đạt được. Mô hình bảo mật đáng tin cậy và an toàn nhất.

Dưới kế hoạch ZK-Rollup lạc quan trên, Giả sử rằng có N người trong mạng Lớp 2 có quyền khởi xướng thách thức. Miễn là một trong số N người thách thức là trung thực và đáng tin cậy và có thể phát hiện lỗi và khởi xướng chứng minh gian lận bất cứ lúc nào, việc chuyển trạng thái Lớp 2 là an toàn. Tất nhiên, ZK-Rollup lạc quan với một mức độ hoàn thành tương đối cao cần đảm bảo rằng cầu nối rút tiền của nó cũng được bảo vệ bởi giao protocô chứng minh gian lận. Tuy nhiên, hầu hết tất cả các Lớp 2 Bitcoin hiện tại không thể đạt được điều này và cần phụ thuộc vào đa chữ ký/MPC. Vậy làm thế nào để chọn đa chữ ký? Việc ký giải pháp MPC đã trở thành một vấn đề gắn liền với an ninh Lớp 2.

Merlin đã chọn dịch vụ MPC của Cobo cho giải pháp cầu. Sử dụng các biện pháp như cách ly ví nóng và lạnh, tài sản cầu được quản lý chung bởi Cobo và Merlin Chain. Mọi hành vi rút tiền cần được xử lý chung bởi các thành viên MPC của Cobo và Merlin Chain. Về cơ bản, tính đáng tin cậy của cầu rút tiền được đảm bảo thông qua việc bảo lãnh tín dụng của tổ chức. Tất nhiên, đây chỉ là một biện pháp tạm thời ở giai đoạn này. Khi dự án ngày càng hoàn 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 tưởng 1/N thông qua việc giới thiệu BitVM và giao thức chống gian lận. Tuy nhiên, việc thực hiện điều này sẽ khó khăn hơn. Cầu rút tiền lớn (hầu hết tất cả các cầu Layer 2 chính thức hiện nay đều dựa vào đa chữ ký).

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

Chiến lược nộp ZKP xác minh hai bước của Lumoz

Trong những cuộc thảo luận trước đó của chúng tôi, chúng tôi đã đào sâu vào khuôn khổ bảo mật của Merlin và khám phá khái niệm đổi mới của ZK-rollups lạc quan. Một yếu tố then chốt trong quỹ đạo công nghệ của Merlin là Prover phi tập trung. Vai trò này quan trọng trong kiến trúc ZK-Rollup, được giao nhiệm vụ tạo ra ZK Proofs cho các lô được phát hành bởi Sequencer. Việc tạo ra chứng minh không cần biết là tốn kém tài nguyên, đặt ra một thách thức đáng kể.

Một chiến lược cơ bản để đẩy nhanh việc tạo ra các bằng chứng ZK là phân chia và song song hóa các nhiệm vụ. Quá trình này, được gọi là song song, liên quan đến việc phá vỡ thế hệ bằng chứng ZK thành các phần riêng biệt. Mỗi phần được xử lý bởi một Tục ngữ khác nhau và cuối cùng, Bộ tổng hợp hợp nhất các bằng chứng riêng lẻ này thành một tổng thể thống nhất. Cách tiếp cận này không chỉ tăng tốc quá trình mà còn phân phối tải tính toán một cách hiệu quả.

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

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 thường được biết đến là tấn công front-running: Giả sử rằng một Aggregator đã thiết lập ZKP, và nó gửi ZKP để nhận phần thưởng. Sau khi các Aggregator khác nhìn thấy nội dung của ZKP, họ công bố cùng một nội dung trước anh ta, tuyên bố 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 tự nhiên nhất mà mọi người nghĩ đến là gán một số nhiệm vụ cụ thể cho mỗi Aggregator. Ví dụ, chỉ Aggregator A mới có thể nhận nhiệm vụ 1, và 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 các rủi ro tập trung. Nếu Aggregator A gặp sự cố về hiệu suất hoặc bị ngắt kết nối, nhiệm vụ 1 sẽ bị kẹt và không thể hoàn thành. Hơn nữa, phương pháp phân bổ nhiệm vụ cho một thực thể duy nhất không thể cải thiện hiệu suất sản xuất thông qua cơ chế khích lệ 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 gọi là Chứng minh hiệu quả trong một bài blog, chỉ ra rằng cần sử dụng các phương tiện cạnh tranh để thúc đẩy sự cạnh tranh giữa các Aggregator khác nhau, và các khuyến khích nên được phân bổ theo nguyên tắc đến trước được phục vụ trước. Aggregator nào gửi ZK-Proof lên chuỗi đầu tiên sẽ nhận được phần thưởng. Tất nhiên, anh ấy không đề cập đến cách giải quyết vấn đề front-running MEV.

Lumoz áp dụng phương pháp xác minh hai bước ZK khi nộp chứng chỉ. Sau khi một Aggregator tạo ra một chứng chỉ ZK, nó không cần phải gửi ra nội dung hoàn chỉnh trước, mà chỉ cần công bố băm ZKP. Nói cách khác, công bố băm (ZKP+Địa chỉ Aggregator). Điều này có nghĩa là, ngay cả khi người khác nhìn thấy giá trị băm, họ không biết nội dung ZKP tương ứng và không thể nhảy thẳng tới;

Nếu ai đó chỉ đơn giản sao chép toàn bộ hash và công bố nó trước, thì không có ý nghĩa, vì hash chứa địa chỉ của một người tổng hợp cụ thể X. Ngay cả khi người tổng hợp A công bố hash trước, khi hình ảnh gốc của hash được tiết lộ, mọi người cũng sẽ thấy rằng địa chỉ của người tổng hợp chứa trong đó là của X, không phải của A.

Qua lược đồ xác minh hai bước này, Merlin (Lumoz) có thể giải quyết vấn đề front-running tồn tại trong quá trình nộp ZKP, từ đó đạt được động lực tạo chứng minh không bằng chứng zero-knowledge cạnh tranh cao, từ đó tăng tốc độ tạo ZKP.

Phantom của Merlin: Tính tương tác đa chuỗi

Theo lộ trình công nghệ của Merlin, họ cũng sẽ hỗ trợ tính tương thích giữa Merlin và các chuỗi EVM khác, con đường triển khai của nó cơ bản giống như ý tưởng Zetachain trước đó. 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 đích, khi nút Merlin cảm nhận yêu cầu tương tác qua chuỗi được phát ra bởi người dùng, nó sẽ kích hoạt công việc tiếp theo trên chuỗi đích.

Ví dụ, một tài khoản EOA được kiểm soát bởi mạng Merlin có thể được triển khai trên Polygon, Khi một người dùng phát ra một hướng dẫn tương thích xuyên chuỗi trên Chuỗi Merlin, Mạng Merlin trước tiên phân tích nội dung của nó và tạo ra dữ liệu giao dịch để thực thi trên chuỗi đích, sau đó, Mạng Oracle thực hiện xử lý chữ ký MPC trên giao dịch để tạo ra số chữ ký. Node Relayer của Merlin sau đó phát hành giao dịch trên Polygon, hoàn tất 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 đích, chẳng hạn như.

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

Tóm tắt

Trong bài viết này, chúng tôi sẽ giải thích một cá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 điều này sẽ cho phép nhiều người hiểu hơn về quy trình làm việc chung của Merlin và có một hiểu biết rõ ràng hơn về mô hình bảo mật của nó. Xét đến việc hệ sinh thái Bitcoin hiện tại đang phát triển mạnh mẽ, chúng tôi tin rằng những hoạt động phổ biến công nghệ như vậy là có giá trị và cần thiết đối với công chúng. Chúng tôi sẽ tiếp tục theo dõi lâu dài về Merlin, bitLayer, B^Square và các dự án khác trong tương lai, để phân tích sâu hơn về giải pháp kỹ thuật của chúng, nên hãy theo dõi!

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được sao chép từ [Gategeek web3], bản quyền thuộc về tác giả gốc [Faust], nếu bạn có bất kỳ ý kiến nào về việc sao chép, vui lòng liên hệ Gate Learn Teamđội sẽ xử lý nó càng sớm càng tốt theo các quy trình liên quan.

2. Quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.

3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn. Không có tham chiếu Gate.io, việc sao chép, phân phối hoặc sao chép trội các bài viết đã dịch là không được phép.