Tóm tắt:· Các cầu ZK triển khai hợp đồng thông minh trên Chuỗi A để trực tiếp nhận và xác minh tiêu đề khối và chứng minh không chứng minh tương ứng từ Chuỗi B, xác nhận tính hợp lệ của các thông điệp qua chuỗi. Đây là kế hoạch cầu an toàn nhất.

• Các Cầu Optimistic/OP sử dụng chứng minh gian lận để thách thức các thông điệp chéo chuỗi không hợp lệ trên chuỗi. Sự hiện diện của chỉ một thách thức đáng tin cậy có thể đảm bảo an toàn cho quỹ tiền của cầu chéo chuỗi.
• Do vấn đề về hạn chế kỹ thuật, mainnet Bitcoin không thể triển khai cầu ZK trực tiếp nhưng có thể đạt được cầu lạc quan thông qua BitVM và chứng minh gian lận. Các nhóm như Bitlayer và Citrea đã áp dụng kế hoạch cầu BitVM, giới thiệu việc ký trước và tích hợp các khái niệm kênh, cho phép người dùng xác định trước quy trình xử lý sau khi thực hiện việc gửi tiền, ngăn chặn cầu kết nối liên chuỗi đánh cắp tiền gửi của người dùng.
• Cầu nối BitVM hoạt động theo mô hình “nạp trước - hoàn lại”, với các nút Hoạt động cụ thể cung cấp tiền cho người dùng rút tiền. Các Nút Hoạt động có thể định kỳ nộp đơn hoàn lại từ một địa chỉ gửi tiền công cộng. Nếu một Nút Hoạt động nộp đơn hoàn lại giả mạo, nó có thể bị thách thức và bị cắt giảm bởi bất kỳ ai.
• Mặc dù về lý thuyết an toàn, cầu nối BitVM gặp vấn đề về tính sống còn/sử dụng và không đáp ứng nhu cầu cụ thể của người dùng về độc lập vốn và chống rửa tiền (vì nó về cơ bản sử dụng mô hình hồ bơi quỹ). Bitlayer giải quyết vấn đề này bằng giải pháp cầu nối OP-DLC. Giải pháp này, tương tự như DLC.link, giới thiệu chứng minh gian lận dựa trên các kênh và DLC để ngăn chặn hành vi gian lận của trận đánh.
• Với sự khó khăn trong việc triển khai BitVM và chứng minh gian lận, các cầu nối DLC sẽ được triển khai trước như một phương tiện tạm thời. Miễn là các rủi ro về niềm tin vào các nhà tiên tri được giải quyết và các nhà tiên tri của bên thứ ba đáng tin cậy và chín chắn hơn được tích hợp, các cầu nối DLC có thể trở thành một hệ thống xác minh rút tiền an toàn hơn so với các cầu nối đa chữ ký ở giai đoạn hiện tại.

Giới thiệu: Kể từ cơn sốt khắc chế năm ngoái, hệ sinh thái Bitcoin đã bước vào một giai đoạn phát triển nhanh chóng. Chỉ trong nửa năm, số dự án dưới bức màn BTC Layer2 đã đạt gần 100. Đơn giản là trở thành một lục địa mới đầy hỗn loạn, nơi cơ hội và lừa đảo cùng tồn tại. Không quá mức khi nói rằng hệ sinh thái Bitcoin hiện tại đã trở thành một “nồi lẩu đa sắc tộc” của Ethereum, Cosmos và Celestia, CKB và hệ sinh thái gốc của Bitcoin. Kết hợp với việc thiếu đi những giọng nói có uy tín, hệ sinh thái Bitcoin đơn giản như thế của thế kỷ 19. Giống như Hoa Kỳ, nó đã trở thành một thế giới mới thu hút lực lượng từ mọi lĩnh vực. Mặc dù điều này mang lại sự thịnh vượng và sức sống cho toàn bộ câu chuyện Web3, nhưng cũng đưa vào rủi ro lớn.

Nhiều dự án đã bắt đầu tạo sức nóng mà không phát hành giải pháp kỹ thuật, sử dụng tên gọi của lớp 2 bản địa, tuyên bố rằng họ có thể hoàn toàn kế thừa sự an toàn của mạng chính Bitcoin; một số người thậm chí còn sử dụng kỹ thuật tuyên truyền để tạo ra các khái niệm, phát minh ra một loạt các danh từ và thuật ngữ kỳ lạ như là cách để quảng bá sự vượt trội của bản thân. Mặc dù việc khoe khoang đã là tình trạng hiện tại của hệ sinh thái Bitcoin, vẫn còn rất nhiều KOL hàng đầu đã đưa ra những phát ngôn khách quan.

Không lâu trước đây, Monanaut, người sáng lập trình duyệt blockchain Mempool, đã công khai chỉ trích các vấn đề hiện tại của hệ sinh thái Bitcoin. Anh ấy đã chỉ ra rõ rằng nếu một Bitcoin Layer 2 đơn giản chỉ sử dụng cầu nối rút tiền đa chữ ký và không thể cho phép người dùng rút tài sản bất cứ lúc nào theo một hình thức không tin cậy, thì dự án đó không phải là một Layer 2 thực sự. Thú vị là Vitalik đã từng chỉ ra rằng Layer 2 ít nhất cũng nên an toàn hơn về mặt bảo mật so với các hệ thống chỉ dựa vào rút tiền đa chữ ký.

Có thể nói rằng Monanaut và Vitalik mạnh mẽ chỉ ra những vấn đề kỹ thuật của Bitcoin Layer 2: Rất nhiều cầu nối rút tiền L2 về cơ bản là cầu nối đa chữ ký. Hoặc là một số tổ chức nổi tiếng giữ một chìa khóa, hoặc sử dụng chữ ký phi tập trung dựa trên POS, nhưng trong mọi trường hợp, mô hình bảo mật của nó dựa trên giả định trung thực của đa số, tức là, mặc định là đa số người tham gia đa chữ ký không kết hợp để làm điều ác.

Loại giải pháp cầu nối rút tiền này phụ thuộc nhiều vào sự bảo lãnh tín dụng không phải là một giải pháp dài hạn. Lịch sử đã cho chúng ta biết rằng cầu nối đa chữ ký sẽ gặp phải nhiều vấn đề sớm muộn. Chỉ có niềm tin được tối giản hoặc việc giữ tài sản có xu hướng hoàn toàn không cần niềm tin. Chỉ có cách đó mới có thể chống đỡ thử thách của thời gian và các hacker. Nhưng tình hình hiện tại của hệ sinh thái Bitcoin là rằng nhiều bên dự án thậm chí chưa phát hành lộ trình kỹ thuật cho cầu nối rút tiền. Không có ý tưởng thiết kế cụ thể cho việc cầu nối nên được tin tưởng hoặc tối giản.

Nhưng đây không phải là tất cả hệ sinh thái Bitcoin. Vẫn còn một số quản lý dự án đã bày tỏ ý kiến về các ý tưởng tối ưu hóa của cầu nối rút tiền. Trong văn bản, chúng ta sẽ phân tích sơ lược về Bitlayer và Citrea’s BitVM bridge, và giới thiệu cầu nối OP-DLC được đề xuất bởi Bitlayer để giải quyết nhược điểm của cầu nối BitVM, từ đó giúp nhiều người hiểu rõ hơn về các rủi ro và ý tưởng thiết kế của các cầu nối liên chuỗi. Điều này rất quan trọng đối với đa số các bên tham gia hệ sinh thái Bitcoin.

Cầu Optimistic: Một kế hoạch xác minh cầu dựa trên chứng minh gian lận

Trong thực tế, bản chất của cầu giao chuỗi rất đơn giản, đó là chứng minh cho chuỗi B rằng một sự kiện cụ thể đã xảy ra trên chuỗi A. Ví dụ, nếu bạn chuyển tài sản từ ETH sang Polygon, bạn cần cầu giao chuỗi để giúp bạn chứng minh rằng bạn đã chuyển tài sản đến một địa chỉ cụ thể trên chuỗi ETH, sau đó bạn có thể nhận được cùng một số tiền trên chuỗi Polygon.

Các cầu nối chéo chuỗi truyền thống thông thường sử dụng chứng thực đa chữ ký. Họ sẽ chỉ định một số nhân chứng dưới chuỗi. Nhân chứng sẽ vận hành các nút của mỗi chuỗi công khai và theo dõi xem ai đã gửi tiền vào địa chỉ thanh toán của cầu nối chéo chuỗi hay không.

Mô hình bảo mật của loại cầu nối giữa chuỗi này cơ bản giống như ví đa chữ ký. Mô hình tin cậy phải được xác định dựa trên phương pháp thiết lập đa chữ ký như M/N, nhưng cuối cùng cơ bản là theo giả thiết đa số trung thực, có nghĩa là hầu hết các bảo trợ mặc định đều không phải là độc hại và tỷ lệ chịu lỗi tương đối hạn chế. Nhiều trường hợp mất cắp cầu nối giữa chuỗi quy mô lớn đã xảy ra trước đó cơ bản là tất cả đều xảy ra trên loại cầu nối đa chữ ký này, entweder do mất cắp hoặc bởi hacker.

Ngược lại, “Cầu lạc quan” dựa trên giao thức chứng minh gian lận và “Cầu ZK” dựa trên ZK an toàn hơn nhiều. Lấy Cầu ZK làm ví dụ, nó sẽ thiết lập một hợp đồng xác thực riêng trên chuỗi mục tiêu để trực tiếp xác minh chứng chỉ rút tiền trên chuỗi, loại bỏ sự phụ thuộc vào những người chứng kiến ngoại chuỗi.

Ví dụ, một cầu ZK bao gồm ETH và Polygon sẽ triển khai một hợp đồng xác minh trên Polygon, hãy gọi là Verifier tạm thời. Node Relayer của ZK Bridge sẽ chuyển tiếp tiêu đề khối Ethereum mới nhất và ZK Proof chứng minh tính hợp lệ cho Verifier, người sẽ xác minh điều đó. Điều này tương đương với việc có hợp đồng Verifier đồng bộ hóa trên chuỗi Polygon và xác minh tiêu đề khối Ethereum mới nhất. Merkle root được ghi lại trong tiêu đề khối liên quan đến tập hợp giao dịch chứa trong khối và có thể được sử dụng để xác minh xem một giao dịch cụ thể có được bao gồm trong khối hay không.

Nếu khối Ethereum có chiều cao khối là 101 chứa 10 câu lệnh chuyển chuỗi chéo từ ETH sang Polygon, Relayer sẽ tạo Chứng minh Merkle liên quan đến 10 giao dịch này và gửi chứng minh đến hợp đồng Verifier trên chuỗi Polygon:

Khối Ethereum số 101 chứa 10 giao dịch qua chuỗi từ ETH đến Polygon. Tất nhiên, cầu ZK có thể chuyển đổi Chứng minh Merkle thành ZK và trực tiếp gửi Chứng minh ZK đến hợp đồng Xác minh viên. Trong suốt quá trình này, người dùng chỉ cần tin tưởng rằng hợp đồng thông minh của cầu giao chuỗi không có lỗ hổng, và rằng công nghệ chứng minh không biết có sẵn sàng và đáng tin cậy. Không cần giới thiệu quá nhiều giả thiết tin cậy như các cầu đa chữ ký truyền thống.

Và”Cầu lạc quan” có sự khác biệt nhất định. Một số cầu lạc quan giữ nguyên các thiết lập tương tự như các nhân chứng, nhưng giới thiệu bằng chứng gian lận và cửa sổ thách thức., sau khi nhân chứng tạo ra một bản ký đa chữ ký cho thông điệp liên chuỗi, mặc dù nó sẽ được gửi đến chuỗi mục tiêu, sự hợp lệ của nó sẽ không được công nhận ngay lập tức. Nó phải vượt qua một khoảng thời gian cửa sổ và không ai nêu câu hỏi trước khi nó có thể được xem xét là hợp lệ. Điều này thực sự hơi giống với ý tưởng của Optimistic Rollup. Tất nhiên, Cầu lạc quan có các mô hình sản phẩm khác, nhưng cuối cùng, an ninh được đảm bảo bởi giao thức bằng chứng gian lận.

Giả định tin cậy của cầu đa chữ ký M / N là N- (M-1) / N. Bạn phải giả định rằng số lượng người độc hại trong mạng nhiều nhất là M-1 và số người trung thực ít nhất là N-(M-1). Giả định tin cậy của cầu ZK là không đáng kể, trong khi giả định tin cậy của cây cầu lạc quan dựa trên bằng chứng gian lận là 1 / N, Chỉ một trong số các nhân chứng N cần phải trung thực và sẵn sàng thách thức các thông điệp chuỗi chéo không hợp lệ được gửi đến chuỗi mục tiêu để đảm bảo an ninh cho cây cầu.

Hiện tại, Do hạn chế về công nghệ, chỉ có thể triển khai cầu ZK theo hướng gửi Bitcoin sang Layer 2. Nếu hướng ngược lại và muốn rút tiền từ Layer 2 về chuỗi Bitcoin, chỉ hỗ trợ cầu đa chữ ký hoặc cầu lạc quan, hoặc mô hình giống như kênh. (Cầu OP-DLC sẽ được mô tả dưới đây giống như một kênh hơn). Để triển khai cầu lạc quan trên chuỗi Bitcoin, cần phải giới thiệu bằng chứng gian lận, và bitVM đã tạo điều kiện tốt cho việc triển khai công nghệ này.

trong các bài viết trước“Một Sự Hiểu Biết Tối Giản về BitVM: Làm thế nào để Xác minh Chứng minh Gian lận trên Chuỗi BTC”Chúng tôi đã giới thiệu ngắn gọn, Bản chất của chứng minh gian lận BitVM là phá vỡ các nhiệm vụ tính toán phức tạp được thực hiện ngoài chuỗi thành một số bước đơn giản, sau đó chọn một bước nhất định để được xác minh trực tiếp trên chuỗi Bitcoin.. Ý tưởng này tương tự như Ethereum optimistic rollups như Arbitrum và Optimism.

(Tài liệu BitVM2 đề cập rằng một tác vụ tính toán sẽ được chia thành một số lượng lớn các bước trung gian thông qua chữ ký Lamport và sau đó bất kỳ ai cũng có thể thách thức một bước trung gian)

Tất nhiên, tuyên bố trên vẫn còn khá mơ hồ, nhưng tôi tin rằng hầu hết mọi người đã hiểu ý nghĩa của chứng chỉ gian lận. Trong bài viết hôm nay, do hạn chế về không gian tổng thể, chúng tôi không có ý định giải thích chi tiết cài đặt kỹ thuật của BitVM và giao thức chứng minh gian lận, vì điều này liên quan đến một loạt quy trình tương tác phức tạp.

Chúng tôi sẽ giới thiệu ngắn gọn về BitLayer, Citrea, BOB và thậm chí cả cây cầu BitVM bản địa được thiết kế chính thức bởi BitVM từ góc độ thiết kế sản phẩm và cơ chế, và cách BitLayer giảm thiểu sự chật chội của cây cầu BitVM thông qua cây cầu OP-DLC., để cho bạn thấy cách thiết kế một giải pháp cầu rút xuất sắc trên chuỗi Bitcoin.

(Sơ đồ mạch của giải pháp cầu nối Bitlayer)

Một phân tích ngắn về nguyên lý cầu nối BitVM giữa Bitlayer và Citrea

Dưới đây, chúng tôi sử dụng giải pháp cầu nối BitVM được công bố bởi Bitlayer, Citrea và Bob như là tư liệu để minh họa quy trình hoạt động chung của cầu nối BitVM.

Trong tài liệu chính thức và blog kỹ thuật của bên dự án nêu trên, bên dự án đã giải thích rõ ý tưởng thiết kế sản phẩm của Cầu rút BitVM (hiện đang ở giai đoạn lý thuyết). Đầu tiên, khi người dùng rút tiền qua cầu BitVM, anh ta cần sử dụng hợp đồng Cầu trên Layer 2 để tạo ra một bản tuyên bố rút tiền. Các thông số chính sau được quy định trong bản tuyên bố rút tiền:

Số lượng BTC đã được ánh xạ mà người rút cần phá hủy trong L2 (như 1 BTC);

Phí xử lý chuyển chuỗi mà người rút dự định trả (giả sử là 0.01 BTC);

Địa chỉ rút tiền của người rút trong L1: L1_receipt;

Số tiền rút của người rút (tức là 1 - 0.01 = 0.99BTC)

Sau đó, Bảng rút tiền trên sẽ được bao gồm trong khối Layer2. Cầu nối BitVM Nút Relayer sẽ đồng bộ hóa khối Layer2, theo dõi bảng rút tiền chứa trong đó, và chuyển tiếp cho Nút Operator, người sẽ thanh toán cho người rút tiền.

Điều cần lưu ý ở đây là Nhà điều hành trả tiền cho người dùng trên chuỗi Bitcoin từ túi của mình, tức là, “tạm ứng” tiền cho Cầu nối BitVM, sau đó, đề nghị bồi thường từ quỹ BitVM Bridge.

Khi xin được hoàn lại chi phí, Người vận hành cần cung cấp bằng chứng về việc thanh toán trước trên chuỗi Bitcoin (tức là, để chứng minh rằng họ đã chuyển tiền đến địa chỉ được chỉ định bởi người rút tiền trên L1, và phải trích xuất thông tin ghi chép chuyển khoản cụ thể chứa trong khối Bitcoin). Đồng thời, Người vận hành cũng phải phát hành một bản báo cáo rút tiền được tạo ra bởi người rút tiền trong L2 (thông qua Merkle Proof, chứng minh rằng bản báo cáo rút tiền được phát hành đến từ khối L2 và không phải là do ảo tưởng). Sau đó, Người vận hành cần chứng minh những điều sau:

Các quỹ được cung cấp bởi Nhà điều hành cho người nhận trên phần của Cầu BitVM bằng số tiền được yêu cầu bởi người nhận trong bản tuyên bố;

Khi Người vận hành đề nghị được hoàn lại, số tiền hoàn lại không được vượt quá số tiền BTC đã được ánh xạ bị hủy bởi người rút tiền ở Layer 2;

Nhà điều hành thực sự đã xử lý tất cả các bảng kê rút tiền L2-L1 trong một khoảng thời gian, và mỗi bảng kê rút tiền có thể được phù hợp với hồ sơ chuyển tiền rút tiền trên chuỗi Bitcoin;

Điều này về cơ bản là một hình phạt đối với Người vận hành vì nói dối về số tiền tạm ứng hoặc từ chối xử lý bản khai báo rút (điều này có thể giải quyết vấn đề chống kiểm duyệt của cầu nối rút). Người vận hành cần so sánh và xác minh các trường chính của chứng chỉ thanh toán tạm ứng và bản khai báo rút ngoại chuỗi để chứng minh rằng số lượng BTC liên quan đến cả hai là bằng nhau.

Nếu Nhà điều hành Cầu rút rút tiền báo cáo số tiền tiền mặt một cách sai lầm, điều đó có nghĩa là Nhà điều hành tuyên bố rằng bằng chứng thanh toán trên L1 khớp với Bản sao rút tiền được phát hành bởi người rút tiền L2, nhưng tình hình thực tế là hai bên không khớp.

Như vậy, điều này chứng minh rằng ZKP của Bằng chứng Thanh toán = Phiếu rút tiền phải sai. Miễn là ZKP này được phát hành, Người thách thức có thể chỉ ra bước nào sai và thách thức nó thông qua giao thức chứng minh gian lận của BitVM2.

Điều cần nhấn mạnh là Bitlayer, Citrea, BOB, ZKBase, vv. đều đã áp dụng con đường BitVM2 mới nhất, đó là phiên bản mới của giải pháp BitVM. Giải pháp này sẽ ZKize các nhiệm vụ tính toán ngoại tuyến, tức là tạo ra ZK Proof cho quá trình tính toán ngoại tuyến, sau đó xác minh Proof, và sau đó chuyển đổi quá trình xác minh ZKP thành Được điều chỉnh thành hình thức của BitVM để thuận tiện cho các thách thức tiếp theo.

Đồng thời, Bằng cách sử dụng Lamport và việc ký trước, thách thức tương tác nhiều vòng của BitVM gốc có thể được tối ưu hóa thành một thách thức không tương tác một vòng, giảm đáng kể độ khó của thách thức.

Quá trình thách thức của BitVM đòi hỏi việc sử dụng một thứ gọi là “cam kết”, tức Commitment. Hãy giải thích về “cam kết” là gì. Nói chung, người nào đó công bố một “cam kết” trên chuỗi Bitcoin sẽ tuyên bố rằng một số dữ liệu được lưu trữ ngoại chuỗi/các nhiệm vụ tính toán xảy ra ngoại chuỗi là chính xác, và tuyên bố liên quan được công bố trên chuỗi là một “cam kết”.

Chúng ta có thể hiểu xấp xỉ Cam kết như một hàm băm của một lượng lớn dữ liệu ngoài chuỗi. Kích thước của Cam kết thường được nén rất nhỏ, nhưng nó có thể được liên kết với một lượng lớn dữ liệu ngoài chuỗi thông qua các phương thức như Merkle Tree và các dữ liệu ngoài chuỗi liên quan này không cần phải được tải lên chuỗi.

Trong giải pháp cầu nối BitVM của BitVM2 và Citrea và BitLayer, Nếu ai đó nghĩ rằng có vấn đề với sự cam kết được phát hành bởi Nhà điều hành Cầu nối Rút tiền trên chuỗi, và cam kết đó được liên kết với quá trình xác minh ZKP không hợp lệ, anh ta có thể khởi xướng một thách thức, và quyền thách thức là không cần phép. (Quá trình tương tác bên trong khá phức tạp và sẽ không được giải thích ở đây)

Khi Nhà điều hành tiến cấp vốn cho hồ bơi quỹ BitVM để thanh toán rút tiền, sau đó xin quyền bồi thường từ hồ bơi quỹ, khi xin quyền, Nhà điều hành phải phát hành Một cam kết để chứng minh rằng số tiền mà nó chuyển đến việc rút tiền trên L1 bằng số tiền rút tiền. Người trả tiền tuyên bố trên L2 rằng anh ấy muốn nhận số tiền đó. Nếu Cam kết đã vượt qua cửa sổ chứng minh gian lận và không bị thách thức, Nhà điều hành có thể rút số tiền bồi thường mà nó cần.

Ở đây chúng tôi muốn giải thích cách duy trì hồ bơi quỹ công cộng của cầu nối BitVM, và đây chính xác là phần quan trọng nhất của cầu nối qua chuỗi. Như chúng ta đã biết, các khoản tiền mà cầu nối qua chuỗi có thể thanh toán cho người nhận tiền đến từ tài sản do người gửi tiền hoặc LP khác đóng góp, và tiền được tiến gần bởi Người vận hành cuối cùng sẽ được rút ra khỏi hồ bơi quỹ công cộng, vì vậy nó hoàn toàn phụ thuộc vào quỹ. Kết quả của việc chuyển khoản, số tiền gửi tiền của người gửi tiền được hút bởi cầu nối BitVM cần phải bằng với số tiền rút tiền của người rút tiền. Vì vậy cách duy trì quỹ tiền gửi là một vấn đề rất quan trọng.

Trong hầu hết các giải pháp kết nối Bitcoin Layer 2, tài sản công khai thường được quản lý thông qua chữ ký đa bên. Tiền gửi của người dùng được tổng hợp vào một tài khoản chữ ký đa bên. Khi cần thực hiện rút tiền, tài khoản chữ ký đa bên này chịu trách nhiệm thực hiện thanh toán. Rõ ràng có một rủi ro lớn về sự tin cậy trong giải pháp này.

Cầu nối BitVM của Bitlayer và Citrea áp dụng ý tưởng tương tự như Lightning Network và các kênh. Trước khi thực hiện việc gửi tiền, người dùng sẽ trước tiên liên lạc với Liên minh BitVM và yêu cầu phía sau ký trước để đạt được các hiệu ứng sau:

Sau khi người dùng chuyển khoản tiền gửi đến địa chỉ nạp tiền, tiền sẽ được khóa trực tiếp trong một địa chỉ Taproot và chỉ có thể được thu bởi Người điều hành của cầu nối. Hơn nữa, Người điều hành chỉ có thể yêu cầu quyền từ địa chỉ Taproot của khoản tiền gửi trên bằng cách đề xuất hoàn lại sau khi tiền rút tiền đến người dùng. Sau khi kết thúc giai đoạn thách thức, Người điều hành có thể rút một số tiền nhất định từ tiền gửi của người dùng.

Trong giải pháp cầu nối BitVM, có một Liên minh BitVM (Liên minh BitVM) được hình thành bởi N thành viên, người lên lịch gửi tiền của người dùng. Tuy nhiên, những thành viên này không thể chiếm đoạt tiền gửi của người dùng một cách riêng tư, vì người dùng sẽ yêu cầu Liên minh BitVM ký trước trước khi chuyển tiền đến địa chỉ được chỉ định để đảm bảo rằng những khoản tiền gửi này chỉ có thể được yêu cầu một cách hợp pháp bởi Người vận hành.

(Sơ đồ của BitVM2 về giải pháp cầu lạc quan của nó)

Để tóm tắt ở mức cao, Cầu BitVM áp dụng các ý tưởng tương tự như các kênh và mạng lưới lightning, cho phép người dùng “xác minh bằng chính mình” và ngăn chặn Liên minh BitVM khỏi việc can thiệp vào hồ bảo đảm mà không cần sự cho phép thông qua việc ký trước. Tiền trong hồ bảo đảm chỉ có thể được sử dụng để hoàn lại cho Người vận hành. Nếu một người vận hành biến tường về số tiền trước, bất kỳ ai cũng có thể đưa ra bằng chứng về gian lận và thách thức nó.

Nếu giải pháp trên có thể được triển khai, cầu nối BitVM sẽ trở thành một trong những cầu nối rút Bitcoin an toàn nhất: Không có vấn đề bảo mật nào với cầu nối này, chỉ có vấn đề về tính sẵn có/tính sống còn. Khi người dùng cố gắng gửi tiền vào BitVM, họ có thể bị kiểm duyệt hoặc từ chối hợp tác bởi Liên minh BitVM, dẫn đến việc không thể gửi tiền thành công. Tuy nhiên, điều này không liên quan đến bảo mật mà là một vấn đề về tính sống còn/tính sẵn có.

Tuy nhiên, việc triển khai cầu nối BitVM tương đối khó khăn. Hơn nữa, nó không thể đáp ứng nhu cầu của một số nhà đầu tư lớn có yêu cầu tương đối cao về tính minh bạch của quỹ: những người này có thể tham gia vào các vấn đề chống rửa tiền và không muốn trộn lẫn tiền của chính họ với tiền của người khác, nhưng cầu nối BitVM sẽ thống nhất chấp nhận tiền của người gửi tiền. , theo một cách nào đó, đó là một hồ bơi nơi có rất nhiều tiền được trộn lẫn.

Để giải quyết vấn đề hoạt động cầu nối BitVM được đề cập ở trên và cung cấp một kênh nhập và xuất quỹ độc lập và sạch sẽ cho những người có nhu cầu cụ thể, nhóm BitLayer đã thêm một giải pháp cầu nối cross-chain bổ sung có tên là OP-DLC. Ngoài cầu nối tích cực của BitVM2, sử dụng một cầu nối DLC tương tự như DLC.link. Cung cấp cho người dùng hai lối vào và ra, cầu nối BitVM và cầu nối OP-DLC, để giảm sự phụ thuộc vào cầu nối BitVM và thậm chí cả Liên minh BitVM.

(Sơ đồ mô phỏng DLC)

DLC: Hợp Đồng Nhật Ký Cẩn Thận

DLC (Discreet Log Contracts) được gọi là hợp đồng nhật ký kín. Được đề xuất bởi Digital Currency Initiative của MIT. Công nghệ này được sử dụng lần đầu tiên để triển khai một hợp đồng thông minh nhẹ trên Bitcoin. Nó không yêu cầu nội dung của hợp đồng được tải lên chuỗi. Thông qua các phương pháp như giao tiếp tương tác ngoại chuỗi và ký trước, các chức năng hợp đồng thông minh bảo vệ quyền riêng tư được triển khai trên chuỗi Bitcoin. Dưới đây chúng tôi sử dụng một trường hợp đánh bạc để minh họa nguyên lý hoạt động của DLC.

Giả sử Alice và Bob muốn đặt cược vào kết quả trận đấu giữa Real Madrid và Barcelona sẽ diễn ra ba ngày sau, và mỗi người trả 1 btc. Nếu Real Madrid thắng, Alice có thể nhận được 1.5 BTC, và Bob chỉ có thể nhận lại 0.5 BTC, tương đương với việc Alice kiếm được 0.5 BTC, và Bob mất 0.5 BTC; nếu Barcelona thắng, Alice chỉ có thể nhận lại 0.5 BTC, và Bob có thể nhận đi 1.5 BTC. Nếu có trận hòa, cả hai người chơi sẽ mỗi người nhận lại 1 BTC.

Nếu chúng ta muốn làm cho quá trình đánh bạc ở trên không tin cậy, chúng ta phải tìm cách ngăn bất kỳ bên nào gian lận. Nếu chúng ta chỉ sử dụng chữ ký đa bên 2/2 hoặc chữ ký đa bên 2/3, thì điều đó rõ ràng không đủ tin cậy. DLC cung cấp giải pháp riêng cho vấn đề này (dựa vào các nhà môi giới bên thứ ba). Toàn bộ luồng công việc có thể được chia làm bốn phần đại khái.

Ví dụ về Alice và Bob như trước, Đầu tiên, cả hai bên tạo một giao dịch quỹ ngoài chuỗi khối, có thể khóa 1 BTC của nhau trên địa chỉ đa chữ ký 2/2., nếu giao dịch quỹ này có hiệu lực, 2 BTC trong địa chỉ đa chữ ký cần được ủy quyền bởi cả hai bên trước khi chúng có thể được chi tiêu.

Tất nhiên, giao dịch Quỹ này hiện chưa được tải lên chuỗi, mà vẫn còn nằm ở phía địa phương của các khách hàng Alice và Bob ngoài chuỗi. Tất cả họ đều biết những hậu quả sẽ là gì sau khi giao dịch này có hiệu lực. Hiện tại, hai bên chỉ thực hiện các phép trừ lý thuyết và sau đó đạt được một loạt các thỏa thuận dựa trên kết quả của các phép trừ đó.

Trong giai đoạn đầu tiên của việc tạo DLC, điều chúng ta có thể xác định là, Cả hai bên sẽ khóa 1 BTC của họ vào một địa chỉ đa chữ ký trong tương lai.

Trong bước thứ hai, cả hai bên tiếp tục suy luận về các sự kiện và kết quả tương lai có thể xảy ra: Ví dụ, khi kết quả trận đấu bóng đá được công bố, có thể có nhiều khả năng như Alice thắng và Bob thua, Alice thua và Bob thắng, hòa, vv. Điều này sẽ dẫn đến các kết quả phân phối khác nhau của Bitcoin trong địa chỉ đa chữ ký 2/2 đã đề cập.

Kết quả khác nhau cần phải được kích hoạt bởi các hướng dẫn giao dịch khác nhau. Những 'Hướng dẫn giao dịch có thể được tải lên chuỗi trong tương lai' này được gọi là CET, tức là Giao dịch Thực thi Hợp đồng. Alice và Bob phải suy luận tất cả CET trước và tạo ra một bộ dữ liệu giao dịch chứa tất cả CET.

Ví dụ, Dựa vào các kết quả có thể của cược giữa Alice và Bob đã đề cập ở trên, Alice tạo ra các CETs sau đây:

CET1: Alice có thể nhận 1.5 BTC từ địa chỉ đa chữ ký, và Bob có thể nhận 0.5 BTC;

CET2: Alice có thể nhận 0.5 BTC từ địa chỉ đa chữ ký, và Bob có thể nhận 1.5 BTC;

CET3: Cả hai bên đều có thể nhận được 1 BTC mỗi bên.

Hãy lấy CET1 làm ví dụ (Alice nhận 1.5 BTC, Bob nhận 0.5 BTC):

Ý nghĩa của giao dịch này là chuyển 1,5 BTC trong địa chỉ đa chữ ký sang một địa chỉ Taproot được kích hoạ bởi kết quả đầu ra của Alice và máy orague, và chuyển 0,5 BTC còn lại sang địa chỉ của Bob. Các sự kiện tương ứng vào thời điểm này là: Real Madrid thắng, Alice thắng 0,5 BTC và Bob thua 0,5 BTC.

Chắc chắn, Để chi tiêu 1,5 BTC này, Alice phải nhận chữ ký kết quả “Real Madrid thắng” được gửi bởi nguồn thông tin.. Nói cách khác, chỉ khi nguồn thông tin xuất thông báo “Real Madrid thắng” thì Alice mới có thể chuyển 1,5 BTC đi. Còn về nội dung của CET2 và CET3, chúng ta có thể suy luận chúng theo cùng một cách và sẽ không đi vào chi tiết ở đây.

Lưu ý rằng CET về cơ bản là một giao dịch cần được tải lên chuỗi để có hiệu lực. Điều gì sẽ xảy ra nếu Alice phát sóng CET1 trước, hoặc trong trường hợp “Barcelona thắng”, vẫn đưa CET1 lên chuỗi mà chỉ có thể được kích hoạt thành công sau khi “Real Madrid thắng”?

Trong sơ đồ trước đó, chúng tôi đã đề cập rằng sau khi CET1 được đưa lên chuỗi, 2 BTC bị khóa trong địa chỉ đa chữ ký gốc sẽ được chuyển đi, 0,5 BTC sẽ được chuyển đến Bob, và 1,5 BTC sẽ được chuyển đến một địa chỉ Taproot. Máy oracale đưa ra kết quả “Chỉ sau khi Real Madrid chiến thắng” thì Alice mới có thể mở khóa BTC bị khóa trong địa chỉ Taproot. Kết quả như dưới đây.

đồng thời,Địa chỉ Taproot này có thể bị khóa thời gian. Nếu Alice không thể rút thành công 1,5 BTC trong khoảng thời gian được chỉ định bởi khóa thời gian, Bob có quyền lấy tiền trực tiếp.

Do đó, miễn là oracle trung thực, Alice không thể lấy đi 1.5 BTC. Khi kết thúc thời gian khóa, Bob có thể lấy đi 1.5 BTC. Ngoài ra, 0.5 BTC được chuyển trực tiếp cho Bob khi CET1 được tải lên chuỗi, tất cả tiền cuối cùng sẽ thuộc về Bob.

Đối với Alice, bất kể cuối cùng cô ấy thắng hay thua, điều có lợi nhất cần làm là đặt CET chính xác vào chuỗi. Đưa CET không hợp lệ vào chuỗi sẽ khiến cô ấy mất nhiều tiền hơn.

Trong thực tế, khi CET được đề cập ở trên được xây dựng, chữ ký schnorr của Taproot đã được cải thiện, có thể hiểu là sử dụng khóa công khai của người báo cáo + kết quả sự kiện để xây dựng địa chỉ độc lập cho các kết quả khác nhau. Sau đó, chỉ khi máy nguồn báo cáo thông báo chữ ký tương ứng với một kết quả cụ thể, BTC bị khóa trên địa chỉ tương ứng với kết quả đó mới có thể được tiêu.

Tất nhiên, có một khả năng bổ sung ở đây. Điều gì sẽ xảy ra nếu Alice biết rằng cô ấy đã thua và đơn giản là không đặt CET1 mà cô ấy xây dựng lên chuỗi? Điều này dễ giải quyết vì Bob có thể xây dựng một CET tùy chỉnh cho vấn đề “Alice thua, Bob thắng”. Hiệu quả đạt được bởi CET này về cơ bản giống như CET được xây dựng bởi Alice, nhưng các chi tiết cụ thể khác nhau, nhưng kết quả là giống nhau.

Những gì được mô tả ở trên là quá trình xây dựng CET quan trọng nhất. Bước thứ ba của DLC là cho Alice và Bob giao tiếp, kiểm tra giao dịch CET được xây dựng bởi bên kia và đưa chữ ký của họ vào CET. Sau khi kiểm tra chính xác, họ có thể tin tưởng lẫn nhau và mỗi người đầu tư 1 BTC, khóa tại các địa chỉ 2/2 multi-signature ban đầu của Alice và Bob, sau đó chờ đợi một CET cụ thể được tải lên chuỗi để kích hoạt quá trình tiếp theo.

Cuối cùng, sau khi máy báo cáo thông báo kết quả và có chữ ký của máy báo cáo trên kết quả, bất kỳ bên nào cũng có thể đưa CET đúng vào chuỗi và để 2 BTC bị khóa trong địa chỉ đa chữ ký được phân phối lại. Nếu người thua đưa CET sai vào chuỗi trước, Nếu bạn đưa CET đúng vào chuỗi, bạn sẽ mất toàn bộ tiền của bạn. Nếu bạn đưa CET đúng vào chuỗi, người thua có thể nhận lại 0.5 BTC.

Ai đó có thể hỏi, DLC khác biệt như thế nào so với chữ ký đa chữ ký 2/3 thông thường? Đầu tiên, nếu nhiều hơn 2/3 đã được ký, bất kỳ hai bên nào cũng có thể cùng nhau để đánh cắp tất cả tài sản, và DLC cho phép đối phương hạn chế mọi kịch bản bằng cách xây dựng một tập hợp CET trước. Ngay cả khi người tiên tri tham gia vào sự xâm phạm, Thiệt hại gây ra thường bị hạn chế.

Thứ hai, đa chữ ký yêu cầu tất cả các bên ký tên cho các giao dịch cụ thể được tải lên chuỗi, trong khi dưới cài đặt của DLC, người tiên tri chỉ cần ký tên kết quả của các sự kiện cụ thể. Nó không cần biết nội dung của CET/giao dịch để tải lên chuỗi. Nó thậm chí không cần biết rằng có hai người, Alice và Bob. Nó chỉ cần hành động như một người tiên tri bình thường. Chỉ tương tác với người dùng một cách bình thường như một máy.

Chúng ta có thể nghĩ rằng Bản chất của DLC là chuyển đổi niềm tin từ các bên tham gia chữ ký đa bên thành niềm tin vào các oracles. Miễn là máy oracles không tham gia vào các hành vi xấu, có thể đảm bảo rằng thiết kế giao thức DLC đủ đáng tin cậy. Lý thuyết, DLC có thể sử dụng một oracles của bên thứ ba tương đối chín và hoàn chỉnh để tránh việc làm xấu. DLC.link và BitLayer tận dụng tính năng này của DLC để chuyển vấn đề niềm tin của cây cầu sang oracles của bên thứ ba.

Ngoài ra, cầu DLC của Bitlayer cũng hỗ trợ các nút truyền thống tự xây dựng, thêm một lớp chứng minh gian lận lên trên điều này. Khi nút truyền thống tự xây dựng đưa CET không hợp lệ lên chuỗi, bất kỳ ai cũng có thể thách thức nó. Về nguyên tắc của cầu OP-DLC của nó, chúng tôi sẽ mô tả ngắn gọn ở dưới đây.

Cầu nối OP-DLC: Kênh DLC + Chứng minh gian lận

Chúng tôi giải thích nguyên tắc vận hành của cầu nối OP-DLC từ quá trình gửi và rút tiền. Giả sử Alice hiện đang gửi 1 BTC vào L2 thông qua cầu nối OP-DLC, Theo cơ chế giao dịch hai bước, Ông Alice tạo ra một giao dịch tiền trước, Như được hiển thị dưới đây:

Thực tế, trước hết chuyển 1 BTC đến địa chỉ Taproot được kiểm soát chung bởi Alice và các thành viên Liên minh BitVM, sau đó bắt đầu một loạt quy trình để tạo ra CET. Nếu một thành viên của Liên minh Cầu BitVM từ chối hợp tác với yêu cầu gửi tiền của Alice, Alice có thể rút tiền ngay sau khi khoá thời gian hết hạn.

Nếu các thành viên của Liên minh BitVM sẵn lòng hợp tác với Alice, cả hai bên có thể sử dụng giao tiếp ngoại xích để trước tiên tạo giao dịch đặt cọc quỹ chính thức (chưa trên chuỗi), cũng như tất cả CET trong kịch bản rút tiền. Sau khi quá trình tạo và xác minh CET hoàn tất, cả hai bên có thể Gửi giao dịch Quỹ lên chuỗi.

Trong dữ liệu Chứng nhận/Ký của giao dịch Quỹ, Alice sẽ chỉ định địa chỉ thanh toán của mình trong Layer2; Sau khi giao dịch Quỹ được tải lên chuỗi, Alice có thể gửi dữ liệu giao dịch quỹ trên vào hợp đồng cầu nối trên Layer 2 để chứng minh rằng cô ấy đã hoàn thành hành động gửi tiền trên chuỗi Bitcoin và đủ điều kiện để hợp đồng cầu nối L2 phát hành Token đến địa chỉ thanh toán được chỉ định.

Sau khi giao dịch Quỹ được kích hoạt, tiền gửi thực sự bị khóa trong địa chỉ đa chữ ký Taproot được kiểm soát chung bởi Alice và các thành viên liên minh BitVM. Tuy nhiên, cần lưu ý rằng đa chữ ký chỉ có thể mở khóa BTC bị khóa bởi địa chỉ thông qua CET, và Liên minh BitVM không thể chuyển tiền đi một cách vô lý.

Tiếp theo, hãy phân tích CET được xây dựng trước bởi Alice và Liên minh BitVM. Những CET này được sử dụng để đáp ứng các tình huống tiềm năng cho việc rút tiền trong tương lai. Ví dụ, Alice có thể đã gửi 1 BTC, nhưng cô ấy chỉ rút 0.3 BTC trong lần rút tiền đầu tiên, và số dư 0.7 BTC đã được chuyển đến hồ bơi quỹ công cộng của Liên minh BitVM. Để kiểm soát, nhưng nếu bạn muốn rút tiền, bạn chỉ có thể thông qua cầu nối BitVM được đề cập ở trên;

Hoặc đơn giản chỉ cần sử dụng 0.7 BTC này để khởi tạo một khoản tiền gửi trước mới. Là tài sản mới được thêm vào cầu DLC, bạn có thể lặp lại quá trình giao dịch tiền gửi và xây dựng CET được đề cập ở trên.

Quá trình trên không khó đề hiệu. Trên thực tế, người gửi tiền Alice và liên minh bitVM hoạt động như đối tác với nhau, tạo ra CET cho các sự kiện rút tiền với số tiền khác nhau, sau đó đến cho phép ngài giác địa đaổ đềm tiền rút tiền do Alice khởi tạo trong Layer 2 để xác định giao dịch nào Alice muốn kích hoạt. Một CET (bạn muốn rút bao nhiêu tiền).

Rủi ro ở đây là máy oracle có thể thông đồng với Liên minh BitVM. Ví dụ: Alice tuyên bố rằng cô ấy muốn rút 0,5 BTC, nhưng máy oracle giả mạo tuyên bố rút tiền, điều này cuối cùng dẫn đến "Alice rút 0,1 BTC và Liên minh BitVM nhận được 0,9 BTC." Lỗi CET trên chuỗi.

Có một số giải pháp cho vấn đề này. Đầu tiên là sử dụng một oracle bên thứ ba với thiết kế tương đối hoàn chỉnh. Ngăn chặn sự kết hợp như vậy (rất khó khăn cho Liên minh BitVM để kết hợp với oracle vào thời điểm này), hoặc để oracle thực hiện staking, oracle cần phải định kỳ công bố Cam kết trên chuỗi Bitcoin, tuyên bố rằng nó đã xử lý yêu cầu rút tiền của người rút một cách trung thực. Bất kỳ ai đều có thể thách thức Cam kết thông qua giao thức chứng minh gian lận của BitVM. Nếu thách thức thành công, oracle xấu sẽ bị cắt giảm.

Dưới thiết kế của cầu OP-DLC, người dùng luôn có thể "tham gia" vào tài sản của mình để ngăn chặn việc tài sản bị lạm dụng bởi Liên minh BitVM. Hơn nữa, thiết kế giống như kênh này mang lại sự tự chủ hơn cho người dùng, và cũng không cần phải pha trộn quỹ của riêng mình với quỹ của người khác. Điều này giống như một giải pháp gửi và rút tiền dạng P2P.

Ngoài ra, Xét đến việc sẽ mất một thời gian để giải pháp BitVM được triển khai, trước khi triển khai, cầu nối DLC sẽ là một mô hình xử lý cầu nối đáng tin cậy hơn so với giải pháp đa chữ ký đơn giản. Giải pháp này cũng có thể được sử dụng như hai lối vào gửi và rút lớn được sử dụng song song với cầu nối BitVM. Nếu một trong số họ thất bại, người dùng có thể sử dụng lối vào khác, đó cũng là một phương pháp dung sai tốt.

Tóm tắt

Giải pháp cầu nối BitVM của BitLayer và Citrea cơ bản là một mô hình “thanh toán trả trước - hoàn lại”, có một nút Quản trị viên dành riêng để chuyển tiền cho người dùng rút tiền, và Quản trị viên có thể đề xuất hoàn lại định kỳ đến địa chỉ gửi tiền công cộng. Nếu một quản trị viên đưa ra đề xuất hoàn lại giả mạo, bất kỳ ai cũng có thể thách thức và cắt giảm số tiền.

Giải pháp của BitVM2 giới thiệu việc ký trước và kết hợp ý tưởng của một kênh để cho phép người dùng giới hạn quá trình xử lý sau khi gửi tiền trước khi thực hiện một khoản tiền gửi chính thức, và không cho các quan chức cầu nối liên chuỗi cơ hội biển thủ tiền gửi của người dùng.

Lý thuyết không có vấn đề về an ninh với cầu này, nhưng có vấn đề về tính sống còn/tính sẵn có, và nó không thể đáp ứng nhu cầu cụ thể của người dùng về sự độc lập về quỹ và chống rửa tiền (nó về cơ bản là một mô hình hồ bơi quỹ), và cũng rất khó để triển khai.

Để đạt được mục tiêu này, Bitlayer đã thêm một giải pháp cầu gọi là OP-DLC, giống như DLC.link và giới thiệu chứng minh gian lận dựa trên các kênh và DLC để ngăn cản máy trung gian oracle của cầu DLC làm ác.

Tuy nhiên, vì BitVM quá khó triển khai, cầu nối DLC sẽ được triển khai trước và trở thành một sự thay thế tạm thời, miễn là rủi ro tin cậy của máy trung gian được giải quyết và một máy trung gian bên thứ ba đáng tin cậy và chín chắn hơn được tích hợp, cầu nối DLC có thể trở thành một giải pháp xác minh rút tiền an toàn hơn cầu nối đa chữ ký ở giai đoạn này.

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

1. Bài viết này được sao chép từ [ 极客web3]. Tất cả bản quyền thuộc về tác giả gốc [Faust & Nickqiao]. Nếu có bất kỳ sự phản đối nào về việc tái bản này, vui lòng liên hệ với Gate Learnđội, và họ sẽ xử lý ngay.
2. Chú ý Miễn Trách Nhiệm: Các quan điểm được thể hiện trong bài viết này chỉ là của tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.