Cầu BitVM và OP-DLC: Cầu nối chuỗi Bitcoin lớp 2 thế hệ mới

Tác giả: Faust & Nickqiao, geek web3

Tóm tắt: · ZK Bridge 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 của chuỗi B và bằng chứng không có kiến ​​thức tương ứng, và xác nhận chuỗi chéo Tính hợp lệ của tin nhắn là giải pháp cầu nối với mức độ bảo mật cao nhất; Optimistic/OP Bridge thách thức các tin nhắn chuỗi chéo không hợp lệ trên chuỗi thông qua các bằng chứng gian lận Miễn là có một kẻ thách thức đáng tin cậy, chuỗi chéo. nhóm vốn cầu chuỗi có thể được đảm bảo Bảo mật;

· Do những hạn chế về mặt kỹ thuật, mạng chính Bitcoin không thể triển khai trực tiếp ZK bridge, nhưng nó có thể được triển khai thông qua BitVM và triển khai Optimistic Bridge chống gian lận. Các nhóm như Bitlayer và Citrea đã áp dụng giải pháp cầu nối BitVM, giới thiệu tính năng ký trước và kết hợp với ý tưởng về các kênh, cho phép người dùng giới hạn quy trình xử lý sau gửi tiền trước khi thực hiện gửi tiền chính thức và ngăn chặn các quan chức cầu nối xuyên chuỗi chiếm đoạt cơ hội gửi tiền của người dùng.

· BitVM Bridge về cơ bản dựa trên mô hình "trả trước-hoàn trả" , với nút Nhà điều hành chuyên dụng sẽ chuyển tiền cho người dùng rút tiền và Nhà điều hành có thể thường xuyên đăng ký hoàn trả vào địa chỉ tiền gửi công khai. Nếu Nhà điều hành tạo đơn đăng ký hoàn tiền sai, bất kỳ ai cũng có thể thách thức và loại bỏ nó;

· Về lý thuyết, cầu nối BitVM Không có vấn đề bảo mật, nhưng có vấn đề về hoạt động/khả năng sẵn sàng và nó không thể đáp ứng nhu cầu của những người dùng cụ thể về độc lập quỹ và chống rửa tiền (bản chất vẫn là mô hình quỹ quỹ). Bitlayer đã bổ sung một giải pháp cầu nối có tên OP-DLC, tương tự như DLC.link và đưa ra bằng chứng gian lận trên cơ sở kênh và DLC để ngăn chặn máy oracle của cầu DLC làm điều ác.

· Do khó khăn trong việc triển khai BitVM và bằng chứng gian lận, cầu nối DLC sẽ được triển khai trước và trở thành cầu nối tạm thời thay thếMiễn là rủi ro tin cậy của oracle được giải quyết và các oracle của bên thứ ba đáng tin cậy và hoàn thiện hơn được tích hợp,Cầu nối DLC có thể trở thành giải pháp xác minh rút tiền an toàn hơn so với cầu đa chữ ký ở giai đoạn này.

Giới thiệu: Kể từ cơn sốt chữ khắc năm ngoái, hệ sinh thái Bitcoin đã bước vào thời kỳ tăng trưởng nhanh chóng. Chỉ trong nửa năm, dưới biểu ngữ của BTC Layer2 The số lượng dự án đã lên tới gần 100,nó đã trở thành một lục địa mới đầy hỗn loạn, cơ hội và lừa đảo cùng tồn tại. Không quá lời khi nói rằng hệ sinh thái Bitcoin hiện tại đã là “nơi hội tụ đa sắc tộc” của Ethereum, Cosmos và Celestia, CKB và hệ sinh thái bản địa Bitcoin. Cùng với việc thiếu tiếng nói có thẩm quyền, hệ sinh thái Bitcoin chỉ đơn giản là như vậy. của thế kỷ 19 Giống như Hoa Kỳ, nó đã trở thành một thế giới mới thu hút các lực lượng từ mọi tầng lớp xã hội. 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 về Web3 nhưng nó cũng gây ra những rủi ro rất lớn.

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

Cách đây không lâu, 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. Ông đã chỉ trích gay gắt out , nếu Lớp Bitcoin 2 chỉ sử dụng cầu 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 kỳ lúc nào dưới hình thức không tin cậy, thì dự án đó không phải là Lớp 2 thực sự. Thật thú vị, Vitalik cũng đã chỉ ra trước đó rằng Lớp 2 ít nhất phải 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 đa chữ ký.

Có thể nói Monanaut và Vitalik đã thẳng thắn chỉ ra các vấn đề kỹ thuật của Bitcoin Lớp 2: Nhiều cầu rút L2 về cơ bản là cầu đa chữ ký,hoặc một số cầu rút nổi tiếng tổ chức nắm giữ 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 tính trung thực của đa số, tức là mặc định phần lớn những người tham gia có nhiều chữ ký không thông đồng để làm điều ác.

Loại giải pháp cầu rút tiền phụ thuộc nhiều vào chứng thực tín dụng này hoàn toàn không phải là một giải pháp lâu dài. -Cầu nối chữ ký sẽ xuất hiện vấn đề, chỉ những phương pháp lưu ký tài sản giảm thiểu độ tin cậy hoặc có xu hướng hoàn toàn không đáng tin cậy mới có thể chịu được thử thách của thời gian và tin tặc. Tuy nhiên, tình hình hiện tại của hệ sinh thái Bitcoin là nhiều bên dự án thậm chí còn chưa công bố lộ trình kỹ thuật cho cây cầu rút tiền. Không có ý tưởng thiết kế nào được thiết lập về mức độ tin cậy hoặc giảm thiểu của cây cầu.

Nhưng đây không phải là tất cả hệ sinh thái Bitcoin. Vẫn còn một số nhà quản lý dự án bày tỏ ý kiến ​​​​về ý tưởng tối ưu hóa cầu rút. Trong bài viết này, chúng tôi sẽ phân tích ngắn gọn về cầu nối BitVM của Bitlayer và Citrea, đồng thời giới thiệu cầu nối OP-DLC do Bitlayer đề xuất nhằm giải quyết những thiếu sót của cầu BitVM, để nhiều người hơn có thể hiểu được những rủi ro và ý tưởng thiết kế của cầu nối chéo cầu chuỗi Điều này rất quan trọng đối với phần lớn những người tham gia hệ sinh thái Bitcoin.

Cầu nối lạc quan: Sơ đồ xác minh cầu nối dựa trên bằng chứng gian lận

Trên thực tế, bản chất của cầu nối chuỗi chéo là rất đơn giản, nghĩa là đối với B Chuỗi chứng minh rằng một sự kiện đã 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ó cầu nối chuỗi chéo để giúp bạn chứng minh rằng bạn thực sự đã chuyển tài sản đến một địa chỉ cụ thể trên chuỗi ETH và sau đó bạn có thể nhận được số tiền tương tự trên chuỗi ETH. Chuỗi đa giác.

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

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

So sánh, "Optimistic Bridge" dựa trên giao thức chống gian lận và "ZK Bridge" dựa trên ZK an toàn hơn nhiều. Lấy ZK Bridge làm ví dụ. Nó sẽ thiết lập một hợp đồng xác thực chuyên dụng trên chuỗi mục tiêu để xác minh trực tiếp chứng chỉ rút tiền trên chuỗi, loại bỏ nhu cầu phụ thuộc vào các nhân chứng ngoài chuỗi.

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

Nếu khối Ethereum có chiều cao khối 101 chứa 10 câu lệnh chuyển chuỗi chéo từ ETH sang Polygon, Relayer sẽ tạo Bằng chứng Merkle liên quan đến 10 giao dịch này và gửi chúng đến hợp đồng Người xác minh trên Bằng chứng gửi chuỗi Đa giác:< /p>

Khối Ethereum số 101 chứa 10 giao dịch chuỗi chéo từ ETH đến Polygon. Tất nhiên, ZK Bridge có thể chuyển đổi Merkle Proof thành ZK và gửi trực tiếp ZK Proof tới hợp đồng Người xác minh. Trong toàn bộ 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 nối chuỗi không có sơ hở và bản thân công nghệ chứng minh không có kiến ​​thức là an toàn và đáng tin cậy. Không cần phải đưa ra quá nhiều giả định về độ tin cậy như truyền thống. cầu đa chữ ký.

"Cầu lạc quan" hơi khác một chút. Một số cầu lạc quan giữ nguyên cài đặt tương tự như nhân chứng, nhưng sẽ đưa ra bằng chứng gian lận và giai đoạn cửa sổ thử tháchSau khi nhân chứng tạo ra nhiều chữ ký cho tin nhắn xuyên chuỗi, mặc dù nó sẽ được gửi đến chuỗi mục tiêu nhưng tính hợp lệ của nó sẽ không được công nhận ngay lập tức mà không có ai có thể thẩm vấn nó. hợp lệ. Điều này thực sự có phần giống với ý tưởng của Optimistic Rollup. Tất nhiên, Optimistic Bridge có các mẫu sản phẩm khác, nhưng xét đến cùng, tính bảo mật được đảm bảo bởi giao thức chống gian lận.

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

Hiện tại,do hạn chế về mặt kỹ thuật, chỉ có thể thực hiện cầu ZK theo hướng gửi tiền từ Bitcoin sang Lớp 2. Nếu hướng đảo ngược và việc rút tiền được thực hiện từ Lớp 2 sang chuỗi Bitcoin thì chỉ có nhiều - Hỗ trợ cầu chữ ký hoặc cầu lạc quan hoặc chế độ giống kênh (cầu OP-DLC được mô tả bên dưới giống kênh hơn). Để triển khai một cầu nối lạc quan trên chuỗi Bitcoin, cần phải đưa ra 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"Giải thích tối giản về BitVM: Cách xác minh bằng chứng gian lận trên chuỗi BTC", chúng tôi đã giới thiệu ngắn gọnBằng chứng gian lận của BitVM, Bản chất là để chia nhỏ 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ố lượng lớn các bước đơn giản, sau đó chọn một bước nhất định và đưa nó vào chuỗi Bitcoin để xác minh trực tiếp. Ý tưởng này tương tự như các bản tổng hợp lạc quan của Ethereum như Arbitrum và Optimism.

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

Tất nhiên, câu nói trên vẫn còn tương đối mơ hồ, nhưng tôi tin rằng hầu hết mọi người đều đã 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 triển khai kỹ thuật của BitVM và giao thức chống 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 và Citrea, BOB và thậm chí cả cầu BitVM gốc được BitVM thiết kế chính thức từ góc độ thiết kế sản phẩm và cơ chế cũng như cách thức Bitlayer vượt qua cầu OP-DLC để giảm bớt tắc nghẽn của cầu BitVMvà chỉ cho bạn cách thiết kế giải pháp cầu rút tiền tốt hơn trên chuỗi Bitcoin.

(Sơ đồ giải pháp bắc cầu của Bitlayer)

Phân tích ngắn gọn về nguyên tắc cầu nối BitVM giữa Bitlayer và Citrea

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

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

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

Số BTC mà người rút dự định trả Phí xử lý chuỗi (giả định là 0,01 BTC);

Địa chỉ thanh toá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áo cáo rút tiền ở trên sẽ được đưa vào khối Lớp 2. Nút chuyển tiếpcủa cầu BitVM sẽ đồng bộ hóa khối Layer2, lắng nghe tuyên bố rút tiền có trong đó và chuyển tiếp nó đến nút Người vận hành, nút này sẽ trả tiền cho người dùng rút tiền.

Điều cần lưu ý ở đây làNhà điều hành trước tiên trả tiền cho người dùng trên chuỗi Bitcoin bằng tiền túi của mình, tức là "tạm ứng" tiền cho BitVM Bridge, sau đó áp dụng cho BitVM Quỹ quỹ cầu bù đắp.

Khi Nhà điều hành nộp đơn xin hoàn tiền, họ cần cung cấp chứng chỉ thanh toán tạm ứng của riêng mình trên chuỗi Bitcoin (để chứng minh rằng họ đã chỉ định người dùng rút tiền trên L1 Địa chỉ đã được chuyển và bản ghi chuyển cụ thể có trong khối Bitcoin phải được trích xuất). Đồng thời, Nhà điều hành cũng phải đưa ra tuyên bố rút tiền do người rút tiền tạo ra trong L2 (thông qua Merkle Proof, chứng minh được rằng tuyên bố rút tiền được đưa ra đến từ khối L2 và không phải được tạo ra ngoài luồng). Sau đó, Nhà điều hành cần chứng minh các vấn đề sau:

Số tiền mà Nhà điều hành ứng trước cho người bị ký phát thay mặt cho BitVM Bridge là bằng nhau theo tuyên bố của người bị ký phát Số tiền thanh toán được yêu cầu;

Khi Nhà điều hành đăng ký hoàn trả, số tiền hoàn trả sẽ không nhiều hơn số lượng BTC được ánh xạ mà người rút tiền đã phá hủy trong Lớp 2;

Người vận hành thực sự đã xử lý tất cả các báo cáo rút tiền L2-L1 trong một khoảng thời gian và mỗi báo cáo rút tiền có thể được khớp với bản ghi chuyển khoản rút tiền trên Chuỗi bitcoin . Nhà điều 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à tuyên bố rút tiền ngoài chuỗi để chứng minh rằng số lượng BTC liên quan đến cả hai đều bằng nhau.

Nếu nhà điều hành cầu rút tiền trình bày sai số tiền tạm ứng, điều đó có nghĩa là nhà điều hành cho rằng bằng chứng thanh toán trên L1 khớp với Tuyên bố rút tiền do người rút tiền L2 đưa ra, nhưng tình hình thực tế là cả hai không khớp nhau .

Điều này chứng tỏ rằng ZKP của Bằng chứng thanh toán = Tuyên bố rút tiền phải sai. Chỉ cần ZKP này được phát hành, Challanger có thể chỉ ra bước nào sai và thách thức nó thông qua giao thức chống gian lận của BitVM2.

Cần nhấn mạnh rằngBitlayer, Citrea, BOB, ZKBase, v.v. đều áp dụng tuyến BitVM2 mới nhất, đây là tuyến đường mới phiên bản BitVM Giải pháp này sẽ ZKize các tác vụ tính toán ngoài chuỗi, nghĩa là tạo Bằng chứng ZK cho quy trình tính toán ngoài chuỗi, sau đó xác minh Bằng chứng và sau đó chuyển đổi quy trình xác minh ZKP thành dạng phù hợp cho BitVM, để tạo điều kiện thuận lợi cho các bước tiếp theo những thách thức.

Đồng thời, bằng cách sử dụng Lamport và chữ ký trước, thử thách tương tác nhiều vòng của BitVM ban đầu có thể được tối ưu hóa thành một- vòng thử thách không tương tác, cực kỳ khó. Độ khó của thử thách đã giảm đi rất nhiều.

Quy trình thử thách của BitVM yêu cầu sử dụng thứ gọi là "cam kết", tức là Cam kết. Hãy giải thích “cam kết” là gì. Nói chung, ai đó công bố “cam kết” trên chuỗi Bitcoin sẽ khẳng định rằng một số dữ liệu nhất định được lưu trữ ngoài chuỗi/tác vụ tính toán xảy ra ngoài chuỗi là chính xác và tuyên bố có liên quan được công bố trên chuỗi là một “cam kết”.

Chúng ta có thể hiểu gần đúng Cam kết như một hàm băm của một số lượng lớn dữ liệu ngoài chuỗi. Bản thân 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 pháp như Merkle Tree và những dữ liệu ngoài chuỗi liên quan này không cần phải tải lên chuỗi.

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

Bởi vì Nhà điều hành ứng tiền cho nhóm quỹ BitVM để thanh toán số tiền rút và sau đó Khi nào yêu cầu hoàn trả từ nguồn vốn, Nhà điều hành phải đưa ra Cam kết để chứng minh rằng số tiền họ chuyển cho người bị ký phát trên L1 bằng với số tiền mà người bị ký phát tuyên bố nhận được trên L2. Nếu Cam kết đã vượt qua cửa sổ chống gian lận và không bị thách thức, Nhà điều hành có thể rút số tiền hoàn trả mà họ cần.

Ở đây chúng tôi muốn giải thích cách duy trì quỹ công cộng của cầu BitVM và đây chính xác là phần quan trọng nhất của chuỗi chéo cầu. Mọi người đều biết rằng số tiền mà cầu nối chuỗi chéo có thể trả cho người bị ký phát đến từ tài sản do người gửi tiền hoặc LP khác đóng góp và số tiền mà Nhà điều hành ứng trước cuối cùng sẽ được rút khỏi nhóm quỹ công, vì vậy Đơn giản là Nhìn vào kết quả chuyển tiền, số tiền gửi được hấp thụ bởi cầu BitVM phải bằng số tiền mà người rút rút. Vậy làm thế nào để giữ được 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 bắc cầu Bitcoin Lớp 2, tài sản công cộng thường được quản lý thông qua nhiều chữ ký và tiền gửi của người dùng được tổng hợp thành tài khoản nhiều chữ ký. cần thiết để chuyển tiền cho người rút tiền, tài khoản nhiều chữ ký này chịu trách nhiệm chuyển tiền. Giải pháp này rõ ràng có rủi ro tin cậy rất lớn.

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 Người dùng sẽ gửi tiền trước khi gửi tiền. . Liên lạc với Liên minh BitVM và yêu cầu họ ký trước để đạt được các hiệu quả sau:

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

Trong giải pháp cầu nối BitVM, có Liên đoàn BitVM (Liên đoàn BitVM) được thành lập bởi N thành viên, những người lên lịch gửi tiền cho người dùng. Nhưng các thành viên 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ư, bởi 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 Nhà điều hành yêu cầu một cách hợp pháp.

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

Tóm tắt rõ ràng, cầu BitVM áp dụng Việc kết hợp các ý tưởng tương tự như các kênh và mạng Lightning, cho phép người dùng "tự xác minh", thông qua việc ký trước, ngăn chặn Liên minh BitVM thao túng nhóm tiền gửi mà không được phép Số tiền trong đó. nhóm tiền gửi chỉ có thể được sử dụng để Yu hoàn trả tiền cho Nhà điều hành. Nếu nhà điều hành trình bày sai số tiền tạm ứng, bất kỳ ai cũng có thể đưa ra bằng chứng 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 BitVM sẽ trở thành một trong những cầu rút Bitcoin an toàn nhất:Loại cầu này sẽ không Có vấn đề về bảo mật, chỉ có vấn đề về tính khả dụng/sự sống động. Khi người dùng cố gắng gửi tiền vào BitVM, họ có thể bị Liên minh BitVM kiểm duyệt hoặc từ chối hợp tác, 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 gì đến bảo mật mà là vấn đề về tính khả dụng/sự tồn tại.

Tuy nhiên, việc triển khai cầu BitVM tương đối khó khăn và không thể đáp ứng được nhu cầu của một số nhà đầu tư lớn có vốn đầu tư tương đối cao. yêu cầu về tính minh bạch của quỹ: những Người này có thể liên quan đến các vấn đề chống rửa tiền và không muốn trộn lẫn tiền của họ với tiền của người khác, nhưng cầu BitVM sẽ thu tiền của người gửi một cách thống nhất và ở một mức độ nào đó, đó là một nhóm 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 nêu trên và cung cấp kênh ra vào quỹ độc lập và sạch sẽ cho những người có nhu cầu cụ thể, Nhóm BitLayer đã bổ sung thêm cho giải pháp cầu nối chuỗi chéo của OP-DLC, ngoài cầu lạc quan của BitVM2, một cầu DLC tương tự như DLC.link được sử dụng để cung cấp cho người dùng hai lối vào và lối ra: cầu BitVM và cầu OP-DLC để giảm sự phụ thuộc vào BitVM Bridge và thậm chí cả Liên minh BitVM.

(sơ đồ DLC)

DLC: Hợp đồng nhật ký thận trọng

DLC (Hợp đồng nhật ký kín đáo) được gọi là hợp đồng nhật ký kín đáo. Nó được đề xuất bởi Sáng kiến ​​tiền tệ kỹ thuật số của MIT. Công nghệ này lần đầu tiên được sử dụng để triển khai hợp đồng thông minh nhẹ trên Bitcoin. đưa nội dung của hợp đồng lên chuỗi và các chức năng hợp đồng thông minh bảo vệ quyền riêng tư có thể được triển khai trên chuỗi Bitcoin 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. Ở đây chúng tôi sử dụng trường hợp cờ bạc để minh họa nguyên tắc 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 3 ngày sau đó, và mỗi người trong số họ sẽ trả 1 btc. Nếu Real Madrid thắng, Alice có thể nhận được 1,5 BTC và Bob chỉ có thể lấy 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ể lấy lại 0,5 BTC và Bob có thể; lấy đi 1,5 BTC. Nếu hòa, cả hai người chơi sẽ nhận lại 1 BTC.

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

Lấy Alice và Bob trước đó làm ví dụ.Đầu tiên, cả hai bên tạo một giao dịch quỹ ngoài chuỗi, giao dịch này có thể chuyển giao từng giao dịch 1 BTC của người khác bị khóa 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 phải được cả hai bên cho phép trước khi chúng có thể được chi tiêu.

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

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

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

Các kết quả khác nhau cần đượ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 này có thể được tải lên chuỗi trong tương lai" được gọi là CET<. /strong >, nghĩa là Giao dịch thực hiện hợp đồng. Alice và Bob phải suy ra trước tất cả CET và tạo tập dữ liệu giao dịch chứa tất cả CET.

Ví dụ: Dựa trên kết quả có thể xảy ra của vụ cá cược giữa Alice và Bob, Alice tạo các CET sau:

CET1:Alice có thể nhận được 1,5 BTC từ địa chỉ có nhiều chữ ký và Bob có thể nhận được 0,5 BTC;

CET2:Alice có thể nhận được 0,5 BTC từ địa chỉ có nhiều chữ ký và Bob có thể nhận được 1,5 BTC;

CET3: Mỗi bên có thể nhận được 1 BTC.

Chúng tôi lấy CET1 làm ví dụ (Alice lấy 1,5 BTC, Bob lấy 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 địa chỉ Taproot được kích hoạt bởi kết quả đầu ra của Alice và máy oracle, đồng thời chuyển 0,5 BTC còn lại đến địa chỉ của Bob . Các sự kiện tương ứng lúc này là: Real Madrid thắng, Alice thắng 0,5 BTC và Bob thua 0,5 BTC.

Tất nhiên, để chi 1,5 BTC này, Alice phải nhận được chữ ký kết quả "Real Madrid thắng" do nhà tiên tri gửi. Nói cách khác, chỉ khi nhà tiên tri đưa ra thông báo “Real Madrid thắng” thì Alice mới có thể chuyển 1,5 BTC đi. Về nội dung của CET2 và CET3, chúng ta có thể suy luận theo cách tương tự và sẽ không đi sâu vào chi tiết ở đây.

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

Trong sơ đồ trước, chúng tôi đã đề cập rằng sau khi CET1 được đưa vào chuỗi, 2 BTC bị khóa trong địa chỉ nhiều chữ ký ban đầu sẽ được 0,5 BTC được chuyển cho Bob và 1,5 BTC được chuyển đến địa chỉ Taproot. Chỉ sau khi nhà tiên tri đưa ra "Real Madrid thắng", Alice mới có thể mở khóa BTC bị khóa trong địa chỉ Taproot. Kết quả như hình dưới đây.

Đồng thời, địa chỉ Taproot này phải chịu các hạn chế về 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 theo thời gian. lock thì Bob có quyền trực tiếp lấy tiền.

Vì vậy, miễn là nhà tiên tri thành thật, Alice không thể lấy đi 1,5 BTC. Khi khóa thời gian hết hạn, Bob có thể lấy đi những thứ này. 1,5 BTC. Ngoài 0,5 BTC được chuyển trực tiếp cho Bob khi CET1 được tải lên chuỗi, tất cả số tiền cuối cùng sẽ thuộc về Bob.

Đối với Alice, dù cuối cùng cô ấy thắng hay thua thì điều có lợi nhất 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.

Trên thực tế, khi CET nói 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 chung của Oracle + kết quả sự kiện. Xây dựng các địa chỉ độc lập cho các kết quả khác nhau. Sau đó, chỉ khi máy oracle thông báo chữ ký tương ứng với một kết quả nào đó thì số BTC bị khóa ở địa chỉ tương ứng với kết quả đó mới được sử dụng.

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

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

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

Một số người có thể hỏi,Sự khác biệt giữa DLC và đa chữ ký 2/3 thông thường là gì? Trước hết, nếu bạn ký nhiều hơn 2/3, bất kỳ hai bên nào cũng có thể thông đồng để đánh cắp toàn bộ tài sản và DLC cho phép đối thủ hạn chế tất cả các kịch bản bằng cách xây dựng trước một bộ CET tham gia thông đồng. và tổn thất 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ý vào các giao dịch cụ thể để được tải lên chuỗi và theo cài đặt của DLC, chỉ có oracle cần ký kết quả của một sự kiện cụ thể, không cần biết nội dung của CET/giao dịch sẽ được tải lên hoặc thậm chí là sự tồn tại của Alice và Bob. Nó chỉ cần tương tác với người dùng bình thường như một nhà tiên tri thông thường.

Chúng tôi có thể nghĩ rằng Bản chất của DLC là biến niềm tin từ những người tham gia có nhiều chữ ký thành niềm tin vào lời tiên tri,

strong>Miễn là cỗ máy tiên tri không tham gia vào các hành động xấu xa, có thể đảm bảo rằng thiết kế giao thức DLC đủ đáng tin cậy. Về mặt lý thuyết, DLC có thể sử dụng lời tiên tri tương đối hoàn thiện và hoàn thiện của bên thứ ba để tránh làm điều ác. DLC.link và BitLayer tận dụng tính năng này của DLC để chuyển vấn đề tin cậy của cây cầu sang nhà tiên tri bên thứ ba.

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

OP-DLC Bridge: kênh DLC + bằng chứng gian lận

Chúng tôi sẽ giải thích nguyên lý hoạt động của cầu OP-DLC trong toàn bộ quá trình gửi và rút tiền. Giả sử rằng Alice hiện gửi 1 BTC vào L2 thông qua cầu OP-DLC Theo cơ chế giao dịch hai bước, ông ALice tạo giao dịch nạp tiền trước, như hiển thị bên dưới:

Cái này thực tếđầu tiên là Chuyển 1 BTC đến địa chỉ Taproot do các thành viên Alice và BitVM Alliance cùng kiểm soát, sau đó bắt đầu một loạt quy trình để tạo CET. Nếu một thành viên của BitVM Bridge Alliance 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 hết thời gian khóa.

Nếu các thành viên của Liên minh BitVM sẵn sàng hợp tác với Alice, trước tiên cả hai bên có thể tạo giao dịch gửi tiền chính thức vào Quỹ thông qua liên lạc ngoài chuỗi (không cần tải nó lên chuỗi trước) và gửi Tất cả CET trong kịch bản quỹ và chỉ sau khi quá trình tạo và xác minh CET hoàn tất, cả hai bên mới gửi giao dịch Quỹ tới chuỗi.

Trong dữ liệu Nhân chứng/chữ ký của giao dịch Quỹ, Alice sẽ chỉ định địa chỉ thanh toán của mình trong Lớp 2;Sau khi giao dịch Quỹ được tải lên tới chuỗi , Alice có thể gửi dữ liệu giao dịch quỹ trên tới hợp đồng cầu nối ở Lớp 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, khoản tiền gửi thực sự bị khóa trong địa chỉ đa chữ ký Taproot do các thành viên Alice và BitVM Alliance cùng kiểm soát. Nhưng xin lưu ý rằng chữ ký đa chữ ký này chỉ có thể mở khóa BTC bị khóa bởi địa chỉ này thông qua CET và Liên minh BitVM không thể chuyển tiền đi mà không có lý do.

Tiếp theo, hãy phân tích CET được Alice và Liên minh BitVM xây dựng trước. Các CET này được sử dụng để đáp ứng các tình huống rút tiền tiềm năng 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à 0,7 BTC còn lại đã được chuyển vào 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ể sử dụng cầu nối BitVM đã đề cập ở trên;

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

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 đóng vai trò là đối tác của nhau, tạo CET cho các sự kiện rút tiền với số tiền khác nhau, sau đó để oracle đọc tuyên bố rút tiền do Alice khởi xướng ở Lớp 2 để xác định xem Alice Bạn muốn kích hoạt CET nào (bạn muốn rút bao nhiêu tiền).

Rủi ro ở đây là máy oracle có thể âm mưu 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, cuối cùng gây ra lỗi CET "Alice rút 0,1 BTC và BitVM Alliance nhận 0,9 BTC" được tải lên chuỗi.

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

Dưới thiết kế của cầu nối OP-DLC, người dùng luôn có thể "nắm tay" vào tài sản của mình để ngăn tài sản bị Liên minh BitVM chiếm đoạt và thiết kế giống như kênh này mang đến cho người dùng nhiều quyền tự chủ hơn và không cần phải trộn tiền của bạn với tiền của người khác. Nó giống như một giải pháp gửi và rút tiền ngang hàng P2P hơn.

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

Tóm tắt

BitLayer và BitVM của Citrea kế hoạch bắc cầu về cơ bản là một mô hình "hoàn trả thanh toán trước". Có một nút Nhà điều hành chuyên dụng để chuyển tiền cho người dùng rút tiền và Nhà điều hành có thể thường xuyên đăng ký hoàn trả vào địa chỉ tiền gửi công khai. Nếu một nhà điều hành làm đơn xin hoàn tiền sai, nó có thể bị thách thức và bị chém bởi bất kỳ ai.

Giải pháp của BitVM2 giới thiệu tính năng ký trước và kết hợp ý tưởng về các kênh cho phép người dùng giới hạn quá trình xử lý sau khi khoản tiền gửi được thực hiện trước khi thực hiện giao dịch chính thức tiền gửi và không cho phép ký chéo. Cơ hội cho các quan chức của ChainBridge chiếm đoạt tiền gửi của người dùng.

Về mặt lý thuyết, loại cầu này không có vấn đề bảo mật, nhưng có vấn đề về khả năng hoạt động/khả năng sử dụng và không thể đáp ứng nhu cầu của người dùng cụ thể để độc lập về tài chính do nhu cầu an toàn và chống rửa tiền (bản chất vẫn là mô hình tập hợp vốn) nên cũng rất khó thực hiện.

Để đạt được mục tiêu này, Bitlayer đã thêm một giải pháp bắc cầu có tên OP-DLC, tương tự như DLC.link và đưa ra bằng chứng gian lận trên cơ sở các kênh và DLC ., để ngăn chặn cỗ máy oracle của cầu DLC làm điều ác.

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