Cầu nối BitVM và OP-DLC: Cách tiếp cận thiết kế thế hệ mới cho cầu nối liên chuỗi Layer2 trên Bitcoin
Tuyển chọn TechFlowTuyển chọn TechFlow
Cầu nối BitVM và OP-DLC: Cách tiếp cận thiết kế thế hệ mới cho cầu nối liên chuỗi Layer2 trên Bitcoin
Hiểu về thiết kế thế hệ cầu nối liên chuỗi mới của Bitcoin thông qua Bitlayer và Citrea.
Chuyên sâu báo cáo Web3Tác giả: Faust & Nickqiao, Geeker web3
Tóm tắt:
-
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 cũng như bằng chứng kiến thức không (zero-knowledge proof) tương ứng từ chuỗi B, nhằm xác nhận tính hợp lệ của tin nhắn xuyên chuỗi. Đây là giải pháp cầu nối an toàn nhất hiện nay; Cầu lạc quan (Optimistic/OP) sử dụng bằng chứng gian lận (fraud proof) để thách thức các tin nhắn xuyên chuỗi không hợp lệ trên chuỗi, chỉ cần tồn tại một bên thách thức đáng tin cậy là có thể đảm bảo an toàn cho quỹ thanh khoản của cây cầu.
-
Do những hạn chế kỹ thuật, mạng lưới chính Bitcoin không thể triển khai trực tiếp cầu ZK, nhưng có thể thực hiện cầu lạc quan thông qua BitVM và bằng chứng gian lận. Bitlayer và Citrea cùng các nhóm khác đã áp dụng phương án cầu BitVM, đưa vào cơ chế ký trước (pre-signature), kết hợp tư tưởng của kênh (channel), cho phép người dùng giới hạn quy trình xử lý sau khi gửi tiền trước khi chính thức gửi tiền, từ đó loại bỏ khả năng tổ chức vận hành cầu chiếm dụng tiền gửi của người dùng.
-
Bản chất cầu BitVM dựa trên mô hình "ứng trước - hoàn trả", với các nút Operator chuyên biệt chịu trách nhiệm chuyển tiền cho người rút tiền. Operator có thể định kỳ nộp đơn xin hoàn lại chi phí từ địa chỉ gửi tiền công cộng. Nếu đơn xin hoàn lại sai lệch, bất kỳ ai cũng có thể thách thức và phạt nặng (Slash) họ.
-
Về mặt lý thuyết, cầu BitVM không có vấn đề an toàn nào, nhưng gặp phải vấn đề về tính sẵn sàng / khả dụng, đồng thời không đáp ứng được nhu cầu độc lập tài sản và chống rửa tiền của một số người dùng cụ thể (vì bản chất vẫn là mô hình quỹ tập trung). Bitlayer bổ sung thêm phương án cầu gọi là OP-DLC, tương tự như DLC.link, tích hợp thêm bằng chứng gian lận trên nền tảng kênh và DLC để ngăn chặn hành vi xấu của oracle trong cầu DLC.
-
Do độ khó triển khai BitVM và bằng chứng gian lận lớn, cầu DLC sẽ được triển khai trước và tạm thời trở thành giải pháp thay thế. Miễn là giải quyết được rủi ro tin cậy đối với oracle, tích hợp oracle bên thứ ba đáng tin cậy và trưởng thành hơn, cầu DLC có thể trở thành phương án xác minh rút tiền an toàn hơn so với cầu đa chữ ký ở giai đoạn hiện tại.
Mở đầu
Kể từ cơn sốt inscription năm ngoái, hệ sinh thái Bitcoin đã bước vào giai đoạn tăng trưởng bùng nổ, trong vòng chưa đầy nửa năm, số lượng dự án tự xưng là Lớp 2 (Layer2) của BTC đã lên tới gần 100, giống như một lục địa mới mọc lên giữa hỗn loạn, nơi cơ hội và lừa đảo đan xen. Không quá lời khi nói rằng, hệ sinh thái Bitcoin hiện nay đã trở thành một "lò luyện kim đa sắc tộc", hấp thụ các dòng lực từ Ethereum, Cosmos & Celestia, CKB đến hệ sinh thái bản địa Bitcoin. Thêm vào đó là sự thiếu vắng tiếng nói uy tín, hệ sinh thái Bitcoin giống như nước Mỹ thế kỷ 19 – vùng đất mới thu hút mọi thế lực đổ về. Điều này vừa mang lại sự sôi động và sức sống phong phú cho câu chuyện Web3, đồng thời cũng tạo ra rủi ro khổng lồ.
Nhiều dự án bắt đầu thổi phồng dữ dội ngay cả khi chưa công bố phương án kỹ thuật nào, tự xưng là Layer2 gốc native, tuyên bố kế thừa toàn bộ tính an toàn của mạng chính Bitcoin; thậm chí còn sử dụng thủ thuật tạo khái niệm, phát minh ra hàng loạt thuật ngữ kỳ lạ làm lời lẽ tuyên truyền sự vượt trội của bản thân. Dù tự quảng cáo đã trở thành trạng thái bình thường của hệ sinh thái Bitcoin, vẫn có không ít KOL hàng đầu lên tiếng khách quan.
Gần đây, nhà sáng lập Monanaut của blockchain explorer Mempool đã công khai chỉ trích những vấn đề hiện tại của hệ sinh thái Bitcoin, ông sắc bén chỉ ra rằng, nếu một Layer2 Bitcoin đơn thuần sử dụng cầu rút tiền dạng đa chữ ký, không thể cho phép người dùng rút tài sản ra bất cứ lúc nào theo cách phi tin cậy (trustless), thì dự án đó không phải là Layer2 thực sự. Thú vị là, trước đó Vitalik cũng từng nhấn mạnh rằng, về mặt đảm bảo an toàn, Layer2 ít nhất phải an toàn hơn hệ thống phụ thuộc đơn thuần vào đa chữ ký.
Có thể nói, Monanaut và Vitalik đã thẳng thắn chỉ rõ vấn đề kỹ thuật của Layer2 Bitcoin: nhiều cầu rút tiền L2 bản chất đều là cầu đa chữ ký, hoặc là vài tổ chức nổi tiếng mỗi bên giữ một khóa riêng, hoặc dùng cơ chế chữ ký phi tập trung dựa trên POS, nhưng dù sao đi nữa, mô hình bảo mật của chúng đều dựa trên giả định đa số trung thực, tức mặc định phần lớn thành viên tham gia đa chữ ký không cấu kết làm điều ác.
Loại phương án cầu rút tiền quá phụ thuộc vào bảo chứng tín dụng này tuyệt nhiên không phải là giải pháp lâu dài. Lịch sử đã chứng minh rằng, cầu đa chữ ký sớm muộn gì cũng sẽ gặp đủ loại vấn đề. Chỉ có các phương thức quản lý tài sản tối thiểu hóa niềm tin hoặc tiến tới phi tin cậy hoàn toàn mới có thể vượt qua thử thách của thời gian và hacker. Tuy nhiên, thực tế hệ sinh thái Bitcoin hiện nay là, nhiều bên phát triển dự án thậm chí chưa công bố lộ trình kỹ thuật cho cầu rút tiền, cũng chẳng có thiết kế rõ ràng về việc làm sao để giảm thiểu hoặc loại bỏ sự phụ thuộc vào niềm tin.
Nhưng điều này không phản ánh toàn bộ hệ sinh thái Bitcoin. Hiện tại vẫn có một số nhóm phát triển đưa ra ý kiến cải tiến cho cầu rút tiền. Trong bài viết này, chúng tôi sẽ phân tích ngắn gọn về cầu BitVM của Bitlayer và Citrea, đồng thời giới thiệu cầu OP-DLC do Bitlayer đề xuất nhằm khắc phục điểm yếu của cầu BitVM, giúp nhiều người hiểu rõ hơn về rủi ro và tư duy thiết kế của cầu nối, điều này cực kỳ quan trọng đối với đông đảo người tham gia hệ sinh thái Bitcoin.
Cầu lạc quan: Phương án xác minh cầu nối dựa trên bằng chứng gian lận
Thực ra, bản chất của cầu nối xuyên chuỗi rất đơn giản: đó là chứng minh trên chuỗi B rằng một sự kiện thực sự đã xảy ra trên chuỗi A. Ví dụ, bạn muốn chuyển tài sản từ ETH sang Polygon, bạn cần để cầu nối giúp chứng minh rằng bạn thực sự đã gửi tài sản vào địa chỉ cụ thể trên mạng Ethereum, sau đó bạn có thể nhận được lượng tài sản tương đương trên mạng Polygon.
Cầu nối truyền thống thường sử dụng mô hình đa chữ ký giám sát (watchman multisig), họ sẽ chỉ định một vài bên giám sát ngoài chuỗi, những người này phải vận hành nút trên các blockchain, theo dõi xem có ai gửi tiền vào địa chỉ nhận của cầu nối hay không.
Mô hình bảo mật của loại cầu nối này về cơ bản giống hệt ví đa chữ ký, cần đánh giá mô hình tin cậy theo cách thiết lập đa chữ ký như M/N, nhưng cuối cùng đều tuân theo giả định đa số trung thực – tức mặc định đa số bên giám sát không có ác ý, khả năng chịu lỗi khá hạn chế. Những vụ tấn công quy mô lớn vào cầu nối từng xảy ra trước đây chủ yếu rơi vào loại cầu đa chữ ký này, nguyên nhân hoặc là nội bộ ăn cắp, hoặc bị hacker tấn công.
Ngược lại, cầu "lạc quan" dựa trên giao thức bằng chứng gian lận và cầu "ZK" dựa trên bằng chứng kiến thức không an toàn hơn nhiều. Lấy cầu ZK làm ví dụ, nó sẽ thiết lập hợp đồng xác minh chuyên dụng trên chuỗi đích, trực tiếp xác minh bằng chứng rút tiền trên chuỗi, từ đó loại bỏ sự phụ thuộc vào các bên giám sát ngoài chuỗi.
Ví dụ, một cầu ZK nối giữa ETH và Polygon sẽ triển khai một hợp đồng xác minh trên Polygon, tạm gọi là Verifier. Nút Relayer của cầu ZK sẽ chuyển tiêu đề khối Ethereum mới nhất và bằng chứng ZK (ZK Proof) chứng minh tính hợp lệ đến hợp đồng Verifier để xác minh. Việc này tương đương với việc hợp đồng Verifier đồng bộ và xác minh tiêu đề khối Ethereum mới nhất ngay trên chuỗi Polygon. Merkle root ghi trong tiêu đề khối có liên hệ với tập giao dịch trong khối, có thể dùng để xác minh liệu một giao dịch cụ thể có nằm trong khối đó hay không.
Nếu trong khối Ethereum ở chiều cao 101 có chứa 10 yêu cầu chuyển tiền xuyên chuỗi từ ETH sang Polygon, nút Relayer sẽ tạo ra Merkle Proof liên quan đến 10 giao dịch này và gửi bằng chứng đến hợp đồng Verifier trên chuỗi Polygon:
Khối Ethereum số 101 chứa 10 giao dịch chuyển tiền từ ETH sang Polygon. Tất nhiên, cầu ZK có thể chuyển đổi Merkle Proof thành dạng ZK, gửi trực tiếp ZK Proof đến hợp đồng Verifier. Trong toàn bộ quy 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 không có lỗi và bản thân công nghệ bằng chứng kiến thức không là an toàn, đáng tin cậy, chứ không cần đặt nhiều giả định tin cậy như cầu đa chữ ký truyền thống.
"Cầu lạc quan/Optimistic Bridge" có chút khác biệt, một số cầu lạc quan vẫn giữ thiết lập giống bên giám sát, nhưng sẽ bổ sung bằng chứng gian lận và thời gian chờ thách thức (challenge window period). Sau khi bên giám sát tạo đa chữ ký cho tin nhắn xuyên chuỗi, dù đã gửi lên chuỗi đích nhưng hiệu lực của nó sẽ không được công nhận ngay lập tức, mà phải trải qua một cửa sổ thời gian và không bị ai phản đối mới được coi là hợp lệ. Ý tưởng này khá giống với Optimistic Rollup. Tất nhiên, cầu lạc quan còn có các mô hình sản phẩm khác, nhưng nhìn chung, mức độ an toàn được đảm bảo nhờ giao thức bằng chứng gian lận.
Mô hình tin cậy của cầu đa chữ ký M/N là N-(M-1)/N, bạn phải giả định số lượng kẻ ác trong mạng tối đa chỉ là M-1, do đó số lượng bên trung thực ít nhất là N-(M-1). Mô hình tin cậy của cầu ZK gần như có thể bỏ qua, còn cầu lạc quan dựa trên bằng chứng gian lận có mô hình tin cậy là 1/N, trong N bên giám sát chỉ cần một bên trung thực sẵn sàng thách thức tin nhắn xuyên chuỗi không hợp lệ đã được gửi lên chuỗi đích, là có thể đảm bảo an toàn cho cầu nối.
Hiện tại, do hạn chế kỹ thuật, hiện chỉ có thể triển khai cầu ZK theo hướng gửi tiền từ Bitcoin sang Layer2, còn ngược lại – rút tiền từ Layer2 về chuỗi Bitcoin – chỉ hỗ trợ cầu đa chữ ký, cầu lạc quan hoặc mô hình tương tự kênh (mô hình OP-DLC nói ở phần sau giống kênh hơn). Để triển khai cầu lạc quan trên chuỗi Bitcoin, cần đưa vào bằng chứng gian lận, và BitVM đã tạo điều kiện thuận lợi cho việc hiện thực hóa công nghệ này.
Trong bài viết trước "Giải thích cực đơn giản về BitVM: Làm sao xác minh bằng chứng gian lận trên chuỗi BTC", chúng tôi từng giới thiệu sơ lược rằng, bằng chứng gian lận của BitVM về bản chất là chia nhỏ tác vụ tính toán phức tạp bên ngoài chuỗi thành vô số bước đơn giản, rồi chọn ra một bước để kiểm tra trực tiếp trên chuỗi Bitcoin. Tư tưởng này khá giống với các optimistic rollup như Arbitrum, Optimism trên Ethereum.
(Tài liệu BitVM2 đề cập việc sử dụng chữ ký Lamport để chia nhỏ một tác vụ tính toán thành nhiều bước trung gian, sau đó bất kỳ ai cũng có thể thách thức một bước trung gian cụ thể)
Dĩ nhiên, cách diễn đạt trên vẫn khá mơ hồ, nhưng tin rằng phần lớn mọi người đã phần nào hiểu được ý nghĩa của bằng chứng gian lận. Trong bài viết hôm nay, do giới hạn dung lượng, chúng tôi không định giải thích chi tiết kỹ thuật hiện thực BitVM và giao thức bằng 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 từ góc độ sản phẩm và thiết kế cơ chế về cầu BitVM bản địa do BitLayer, Citrea, BOB và cả đội ngũ chính thức BitVM thiết kế, cũng như cách Bitlayer dùng cầu OP-DLC để giảm nhẹ điểm nghẽn của cầu BitVM, nhằm minh họa cho mọi người thấy cách thiết kế phương án cầu rút tiền tốt hơn trên chuỗi Bitcoin.
(Sơ đồ minh họa phương án cầu nối của Bitlayer)
Phân tích ngắn gọn nguyên lý cầu BitVM của Bitlayer và Citrea
Ở phần sau, chúng tôi sẽ lấy phương án cầu BitVM đã công bố bởi Bitlayer, Citrea và Bob làm tư liệu, để làm rõ quy trình hoạt động tổng thể của cầu BitVM.
Trong tài liệu chính thức và blog kỹ thuật, các nhóm phát triển trên đã giải thích khá rõ ràng về tư duy 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 tiên, khi người dùng rút tiền qua cầu BitVM, cần dùng hợp đồng Bridge trên Layer2 để tạo ra tuyên bố rút tiền, tuyên bố rút tiền này sẽ chỉ định các tham số then chốt sau:
-
Số lượng BTC bản đồ hóa mà người rút tiền cần hủy trên L2 (ví dụ: 1 BTC);
-
Phí xuyên chuỗi mà người rút tiền dự định trả (giả sử là 0,01 BTC);
-
Địa chỉ nhận tiền trên L1 của người rút tiền: L1_receipt;
-
Số tiền người rút tiền sẽ nhận được (tức là 1 – 0,01 = 0,99 BTC)
Sau đó, tuyên bố rút tiền trên sẽ được đưa vào khối trên Layer2. Nút Relayer của cầu BitVM sẽ đồng bộ khối Layer2, theo dõi các tuyên bố rút tiền trong đó và chuyển tiếp đến nút Operator, để bên này chuyển tiền cho người rút tiền.
Lưu ý rằng, Operator trước tiên tự掏 tiền để chuyển tiền cho người dùng trên chuỗi Bitcoin, tức là "ứng trước" vốn cho cầu BitVM, sau đó mới xin hoàn lại từ quỹ của cầu BitVM.
Khi xin hoàn tiền, Operator cần cung cấp bằng chứng đã ứng tiền trên chuỗi Bitcoin (tức chứng minh mình đã chuyển tiền đến địa chỉ chỉ định của người rút tiền trên L1, phải trích xuất giao dịch chuyển tiền cụ thể trong khối Bitcoin). Đồng thời, Operator cũng phải xuất trình tuyên bố rút tiền mà người rút tiền tạo ra trên L2 (bằng Merkle Proof, chứng minh tuyên bố rút tiền được cung cấp đến từ khối L2 chứ không phải do tự bịa ra). Sau đó, Operator cần chứng minh các điều sau:
-
Số tiền Operator ứng trước cho người rút tiền bằng đúng số tiền người rút yêu cầu nhận;
-
Số tiền Operator xin hoàn lại không vượt quá số lượng BTC bản đồ hóa mà người rút tiền đã hủy trên Layer2;
-
Operator quả thực đã xử lý toàn bộ các tuyên bố rút tiền L2-L1 trong khoảng thời gian nhất định, mỗi tuyên bố rút tiền đều khớp với ghi chép chuyển tiền trên chuỗi Bitcoin;
Đây bản chất là hình phạt đối với hành vi khai man số tiền ứng trước hoặc từ chối xử lý yêu cầu rút tiền của Operator (có thể giải quyết vấn đề kháng kiểm duyệt của cầu rút tiền). Operator cần so sánh và xác minh bên ngoài chuỗi các trường dữ liệu then chốt của bằng chứng ứng tiền và tuyên bố rút tiền, chứng minh số lượng BTC liên quan trong hai bên là bằng nhau.
Nếu Operator của cầu rút tiền khai man số tiền ứng trước, nghĩa là Operator tuyên bố bằng chứng chuyển tiền (payment proof) trên L1 khớp với Tuyên bố rút tiền (Withdrawal Statement) của người rút tiền trên L2, nhưng thực tế lại không khớp.
Như vậy, bằng chứng ZKP chứng minh Payment Proof = Withdrawal Statement chắc chắn là sai. Chỉ cần ZKP này được công bố, Challenger có thể chỉ ra bước nào sai và thách thức thông qua giao thức bằng chứng gian lận BitVM2.
Cần nhấn mạnh rằng, Bitlayer, Citrea, BOB, ZKBase và một số dự án khác đều áp dụng tuyến đường BitVM2 mới nhất, tức phiên bản mới của phương án BitVM, phương án này sẽ chuyển hóa tác vụ tính toán ngoài chuỗi thành dạng ZK, tức tạo ZK Proof cho quá trình tính toán bên ngoài chuỗi, sau đó xác minh Proof, rồi chuyển đổi quá trình xác minh ZKP thành dạng phù hợp với BitVM để tiện cho việc thách thức sau này.
Đồng thời, việc sử dụng Lamport và chữ ký trước (pre-signature) có thể tối ưu hóa thách thức tương tác đa vòng ban đầu của BitVM thành thách thức đơn vòng, phi tương tác, giảm đáng kể độ khó thách thức.
Quy trình thách thức BitVM cần dùng đến một thứ gọi là "cam kết" (Commitment). Chúng ta hãy giải thích cam kết là gì. Về cơ bản, người công bố "cam kết" trên chuỗi Bitcoin sẽ tuyên bố rằng một số dữ liệu lưu trữ ngoài chuỗi hoặc tác vụ tính toán xảy ra ngoài chuỗi là hoàn toàn chính xác, và tuyên bố liên quan được đăng tải lên chuỗi chính là "cam kết".
Chúng ta có thể xem Commitment như là hàm băm (hash) của một lượng lớn dữ liệu ngoài chuỗi. Bản thân Cam kết thường được nén rất nhỏ, nhưng có thể gắn với lượng lớn dữ liệu ngoài chuỗi thông qua Merkle Tree, và các dữ liệu ngoài chuỗi liên kết này không cần phải đưa lên chuỗi.
Trong phương án cầu BitVM của BitVM2, Citrea và BitLayer, nếu ai đó cho rằng cam kết mà Operator của cầu rút tiền công bố trên chuỗi có vấn đề, và cam kết này liên quan đến quy trình xác minh ZKP không hợp lệ, họ có thể khởi động thách thức, và quyền thách thức là mở (Permissionless). (Quy trình tương tác bên trong khá phức tạp, ở đây không đi sâu giải thích)
Do Operator là bên ứng trước vốn từ quỹ BitVM để chuyển tiền cho người rút, sau đó xin hoàn lại từ quỹ, nên khi xin hoàn, Operator phải công bố một Cam kết, chứng minh số tiền đã chuyển cho người rút trên L1 bằng đúng số tiền người rút tuyên bố nhận trên L2. Nếu Cam kết này trải qua cửa sổ thời gian bằng chứng gian lận mà không bị thách thức, Operator có thể rút số tiền hoàn lại cần thiết.
Tại đây, chúng ta cần giải thích cách quỹ công cộng của cầu BitVM được duy trì, và đây chính là phần then chốt nhất của cầu nối xuyên chuỗi. Ai cũng biết rằng, số tiền cầu nối có thể chi trả cho người rút đến từ tiền gửi của người gửi hoặc các LP đóng góp, và số tiền Operator ứng trước cuối cùng đều phải rút từ quỹ công cộng, do đó xét về kết quả chuyển tiền, số tiền Deposit mà cầu BitVM nhận được phải bằng số tiền Withdraw của người rút. Vậy thì, việc quản lý tiền Deposit như thế nào là một vấn đề rất quan trọng.
Trong hầu hết các phương án cầu nối của Layer2 Bitcoin, người ta thường dùng đa chữ ký để quản lý tài sản công cộng, tiền gửi của người dùng được tập hợp vào một tài khoản đa chữ ký, khi cần chuyển tiền cho người rút, tài khoản đa chữ ký này sẽ chịu trách nhiệm chuyển tiền. Rõ ràng phương án này tiềm ẩn rủi ro tin cậy rất lớn.
Cầu BitVM của Bitlayer và Citrea sử dụng tư tưởng tương tự mạng Lightning và kênh, người dùng trước khi gửi tiền sẽ liên lạc trước với Liên minh BitVM (BitVM Federation) để thực hiện chữ ký trước, đạt được hiệu quả như sau:
Sau khi người dùng chuyển tiền vào địa chỉ nạp tiền, số tiền này sẽ bị khóa ngay trong một địa chỉ Taproot, chỉ có thể do Operator của cầu lấy ra. Hơn nữa, Operator chỉ có thể nhận tiền từ quỹ công cộng sau khi đã ứng trước tiền rút cho người dùng thông qua quy trình xin hoàn. Sau khi hết thời gian thách thức, Operator mới có thể rút một lượng tiền gửi nhất định của người dùng.
Trong phương án cầu BitVM, tồn tại Liên minh BitVM (BitVM Federation) gồm N thành viên, do họ điều phối tiền gửi của người dùng. Nhưng N thành viên này không thể tự ý chiếm dụng tiền gửi của người dùng, vì trước khi chuyển tiền vào địa chỉ chỉ định, người dùng sẽ yêu cầu Liên minh BitVM phải thực hiện chữ ký trước, đảm bảo số tiền gửi này chỉ có thể được Operator hợp pháp rút ra.
(Sơ đồ minh họa phương án cầu lạc quan của BitVM2)
Tóm lại, cầu BitVM áp dụng tư tưởng tương tự kênh và mạng Lightning, cho phép người dùng "tự xác minh (verify by yourself)", thông qua chữ ký trước để đảm bảo Liên minh BitVM không thể tùy tiện thao túng quỹ gửi tiền, tiền trong quỹ chỉ có thể dùng để hoàn tiền cho Operator. Nếu Operator khai man số tiền ứng trước, bất kỳ ai cũng có thể công bố bằng chứng gian lận và thách thức.
Nếu phương án trên có thể hiện thực hóa, cầu BitVM sẽ trở thành một trong những cầu rút tiền Bitcoin an toàn nhất: Loại cầu này không có vấn đề an toàn, chỉ có vấn đề về tính sẵn sàng / khả dụng. Người dùng khi cố gắng gửi tiền vào BitVM có thể bị Liên minh BitVM kiểm duyệt hoặc từ chối hợp tác, dẫn đến không thể gửi tiền thành công, nhưng điều này không liên quan đến an toàn mà thuộc về vấn đề sẵn sàng / khả dụng.
Tuy nhiên, độ khó triển khai cầu BitVM khá lớn, và cũng không thể đáp ứng nhu cầu của một số đại gia đặc biệt về độ minh bạch tài chính: những người này có thể liên quan đến vấn đề chống rửa tiền, không muốn tiền của mình bị trộn lẫn với tiền của người khác, nhưng cầu BitVM sẽ tập hợp tiền của người gửi vào một chỗ, về bản chất là một cái hồ chứa nhiều tiền trộn lẫn.
Để giải quyết vấn đề sẵn sàng của cầu BitVM và cung cấp kênh vào-ra độc lập, sạch sẽ cho những người có nhu cầu đặc biệt, đội ngũ BitLayer bổ sung thêm phương án cầu xuyên chuỗi tên là OP-DLC, ngoài cầu lạc quan BitVM2, còn áp dụng cầu DLC kiểu DLC.link, cung cấp cho người dùng hai cổng vào-ra là cầu BitVM và cầu OP-DLC, nhằm giảm sự phụ thuộc vào cầu BitVM và Liên minh BitVM.
(Sơ đồ nguyên lý DLC)
DLC: Hợp đồng nhật ký thận trọng
DLC (Discreet Log Contracts) – Hợp đồng nhật ký thận trọng, do Sáng kiến Tiền tệ Kỹ thuật số (Digital Currency Initiative) thuộc MIT đề xuất, công nghệ này ban đầu dùng để hiện thực một dạng hợp đồng thông minh nhẹ trên Bitcoin, không cần đưa nội dung hợp đồng lên chuỗi, mà vẫn có thể thông qua giao tiếp tương tác ngoài chuỗi và chữ ký trước để hiện thực chức năng hợp đồng thông minh bảo vệ quyền riêng tư trên chuỗi Bitcoin. Dưới đây chúng tôi sẽ dùng một ví dụ cá cược bóng đá để minh họa nguyên lý hoạt động của DLC.
Giả sử Alice và Bob muốn cá cược kết quả trận đấu Real Madrid vs Barcelona diễn ra sau 3 ngày, mỗi người đặt 1 BTC. Nếu Real thắng, Alice nhận 1,5 BTC, Bob chỉ nhận lại 0,5 BTC, tương đương Alice lãi 0,5 BTC, Bob lỗ 0,5 BTC; nếu Barca thắng, Alice chỉ nhận lại 0,5 BTC, Bob nhận 1,5 BTC. Nếu hòa, mỗi người nhận lại 1 BTC.
Nếu muốn quá trình cá cược này trở nên phi tin cậy, cần tìm cách ngăn chặn bất kỳ bên nào quỵt nợ. Nếu chỉ dùng đa chữ ký 2/2 hoặc 2/3, rõ ràng vẫn chưa đủ phi tin cậy. DLC đưa ra giải pháp riêng cho điểm này (phụ thuộc vào oracle bên thứ ba). Toàn bộ quy trình hoạt động có thể chia thành bốn phần.
Lấy ví dụ Alice và Bob ở trên, trước tiên, hai bên tạo giao dịch fund ngoài chuỗi, khóa 1 BTC của mỗi người vào địa chỉ đa chữ ký 2/2. Nếu giao dịch fund này có hiệu lực, 2 BTC trong địa chỉ đa chữ ký này cần cả hai bên ủy quyền mới có thể chi tiêu.
Tất nhiên, giao dịch Fund này chưa đưa lên chuỗi, chỉ lưu trữ cục bộ trong máy khách của Alice và Bob, họ đều biết hậu quả nếu giao dịch này được kích hoạt. Hiện tại hai bên chỉ đang suy luận lý thuyết, sau đó dựa trên kết quả suy luận để đạt được một loạt thỏa thuận.
Ở giai đoạn đầu tiên khi tạo DLC, ta có thể khẳng định rằng, hai bên sẽ trong tương lai khóa 1 BTC của mỗi người vào một địa chỉ đa chữ ký.
Bước 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ụ, sau khi kết quả trận đấu công bố, có thể là Alice thắng Bob thua, Alice thua Bob thắng, hòa... nhiều khả năng, dẫn đến việc phân phối 2 BTC trong địa chỉ đa chữ ký 2/2 trên có kết quả khác nhau.
Các kết quả khác nhau cần lệnh giao dịch khác nhau để kích hoạt, những "lệnh giao dịch có thể đưa lên chuỗi trong tương lai" này được gọi là CET (Contract Execution Transaction - Giao dịch Thực thi Hợp đồng). Alice và Bob cần tiên đoán trước tất cả CET, tạo tập dữ liệu giao dịch chứa toàn bộ CET.
Ví dụ, dựa trên các kết quả có thể xảy ra trong cuộc cá cược giữa Alice và Bob, Alice tạo ra các CET sau:
-
CET1: Alice có thể nhận 1,5 BTC từ địa chỉ đa chữ ký, Bob nhận 0,5 BTC;
-
CET2: Alice nhận 0,5 BTC từ địa chỉ đa chữ ký, Bob nhận 1,5 BTC;
-
CET3: Mỗi người nhận 1 BTC.
Lấy CET1 làm ví dụ (Alice nhận 1,5 BTC, Bob nhận 0,5 BTC):
Giao dịch này có nghĩa là chuyển 1,5 BTC từ địa chỉ đa chữ ký đến một địa chỉ Taproot được kích hoạt bởi Alice và kết quả đầu ra từ oracle, đồng thời chuyển 0,5 BTC còn lại đến địa chỉ của Bob. Sự kiện tương ứng là: Real thắng, Alice thắng 0,5 BTC, Bob thua 0,5 BTC.
Tất nhiên, để chi tiêu 1,5 BTC này, Alice phải nhận được chữ ký từ oracle xác nhận "Real thắng". Nói cách khác, chỉ khi oracle công bố kết quả "Real thắng", Alice mới có thể chuyển đi 1,5 BTC này. Với CET2 và CET3, chúng ta có thể suy luận tương tự, ở đây không nhắc lại.
Lưu ý rằng, CET bản chất là một giao dịch chờ đưa lên chuỗi và có hiệu lực, nếu Alice đưa CET1 lên mạng trước thời điểm, hoặc trong trường hợp "Barca thắng", vẫn cố đưa CET1 – chỉ có thể kích hoạt khi "Real thắng" – lên chuỗi, chuyện gì sẽ xảy ra?
Trong sơ đồ trước, chúng tôi đề cập rằng, sau khi CET1 được đưa lên chuỗi, sẽ chuyển 2 BTC bị khóa trong địa chỉ đa chữ ký ban đầu đi: 0,5 BTC chuyển cho Bob, 1,5 BTC chuyển đến một địa chỉ Taproot, Alice chỉ có thể mở khóa số BTC bị khóa trong địa chỉ Taproot này sau khi oracle xuất ra kết quả "Real thắng". Hiệu quả như hình dưới.
Đồng thời, địa chỉ Taproot này bị giới hạn bởi khóa thời gian (time lock), nếu trong cửa sổ thời gian quy định, Alice không thể rút thành công 1,5 BTC, Bob có quyền lấy toàn bộ số tiền này.
Vì vậy, miễn là oracle trung thực, Alice không thể lấy được 1,5 BTC này, khi thời gian khóa hết hạn, Bob có thể lấy toàn bộ 1,5 BTC. Cộng thêm 0,5 BTC mà CET1 chuyển trực tiếp cho Bob khi lên chuỗi, cuối cùng toàn bộ tiền sẽ thuộc về Bob.
Đối với Alice, dù thắng hay thua, lựa chọn có lợi nhất là đưa CET đúng lên chuỗi, việc đưa CET vô hiệu lên chuỗi sẽ khiến cô thua nhiều hơn.
Thực ra khi xây dựng CET, đã cải tiến chữ ký schnorr của Taproot, có thể hiểu là sử dụng khóa công khai oracle + kết quả sự kiện để xây dựng các địa chỉ độc lập riêng biệt cho từng kết quả. Sau đó, khi oracle công bố chữ ký tương ứng với một kết quả, mới có thể chi tiêu số BTC bị khóa trên địa chỉ tương ứng.
Tất nhiên, ở đây tồn tại một khả năng bổ sung. Giả sử Alice biết mình thua, liền từ chối đưa CET1 do mình xây dựng lên chuỗi, lúc đó phải làm sao? Điều này rất dễ giải quyết, vì Bob có thể tự xây dựng CET tùy chỉnh cho sự kiện "Alice thua, Bob thắng", hiệu quả CET này cơ bản giống với CET do Alice xây dựng, chỉ chi tiết cụ thể khác nhau, nhưng kết quả là như nhau.
Trên đây là quy trình xây dựng CET then chốt nhất. Bước thứ ba của DLC là Alice và Bob giao tiếp với nhau, kiểm tra giao dịch CET do đối phương xây dựng, đính kèm chữ ký của mình cho CET đó, sau khi kiểm tra không có lỗi, có thể tin tưởng nhau, rồi mỗi người góp 1 BTC, khóa vào địa chỉ đa chữ ký 2/2 ban đầu, sau đó chờ một CET nào đó được đưa lên chuỗi để kích hoạt quy trình sau.
Cuối cùng, khi oracle công bố kết quả, sau khi nhận được chữ ký của oracle cho kết quả đó, bất kỳ bên nào cũng có thể đưa CET đúng lên chuỗi, để 2 BTC bị khóa trong địa chỉ đa chữ ký được phân phối lại. Nếu bên thua cố tình đưa CET sai lên trước, họ sẽ mất toàn bộ tiền; nếu đưa CET đúng lên, bên thua vẫn có thể nhận lại 0,5 BTC.
Có người có thể hỏi, DLC khác gì với đa chữ ký 2/3 thông thường? Trước hết, trong mô hình 2/3 đa chữ ký, bất kỳ hai bên nào cấu kết đều có thể đánh cắp toàn bộ tài sản, trong khi DLC thông qua việc xây dựng trước tập CET, giới hạn toàn bộ kịch bản giữa các bên đối đầu, ngay cả khi oracle cấu kết, thiệt hại gây ra cũng thường rất hạn chế.
Thứ hai, đa chữ ký yêu cầu các bên ký vào giao dịch cụ thể định đưa lên chuỗi, trong khi với thiết lập DLC, oracle chỉ cần ký vào kết quả của sự kiện cụ thể, không cần biết nội dung CET/giao dịch định đưa lên chuỗi, thậm chí hoàn toàn không cần biết sự tồn tại của Alice và Bob, chỉ cần tương tác bình thường như oracle thông thường với người dùng.
Chúng ta có thể cho rằng, DLC về bản chất là chuyển sự tin cậy dành cho các bên tham gia đa chữ ký thành sự tin cậy dành cho oracle, miễn là oracle không làm điều ác, có thể đảm bảo thiết kế giao thức DLC đủ phi tin cậy. Về lý thuyết, DLC có thể sử dụng oracle bên thứ ba trưởng thành, đáng tin cậy để tránh hành vi xấu. DLC.link và BitLayer tận dụng đặc điểm này của DLC, chuyển vấn đề tin cậy của cầu nối sang oracle bên thứ ba.
Ngoài ra, cầu DLC của Bitlayer còn hỗ trợ nút oracle tự xây dựng, trên đó thêm một lớp bằng chứng gian lận, cho phép bất kỳ ai thách thức khi oracle tự xây dựng đưa CET vô hiệu lên chuỗi. Về nguyên lý cầu OP-DLC, chúng tôi sẽ trình bày ngắn gọn ở phần sau.
Cầu OP-DLC: Kênh DLC + Bằng chứng gian lận
Chúng tôi sẽ giải thích nguyên lý vận hành của cầu OP-DLC từ toàn bộ quy trình gửi và rút tiền. Giả sử hiện tại Alice gửi 1 BTC vào L2 qua cầu OP-DLC, theo cơ chế hai giao dịch, Alice trước tiên tạo một giao dịch pre-fund, như hình dưới:
Đây thực chất là chuyển trước 1 BTC vào địa chỉ Taproot do Alice và thành viên Liên minh BitVM cùng kiểm soát, sau đó bắt đầu quy trình tạo CET. Nếu các thành viên Liên minh BitVM từ chối phối hợp yêu cầu gửi tiền của Alice, Alice có thể đợi hết thời gian khóa rồi rút tiền ngay lập tức.
Nếu các thành viên Liên minh BitVM sẵn sàng phối hợp với Alice, hai bên sẽ thông qua giao tiếp ngoài chuỗi trước tiên tạo giao dịch gửi tiền (fund) chính thức (chưa đưa lên chuỗi), cùng toàn bộ CET trong kịch bản rút tiền, sau khi CET được tạo và kiểm tra xong, hai bên mới đưa giao dịch fund lên chuỗi.
Trong phần Witness/chữ ký của giao dịch fund, Alice sẽ chỉ định địa chỉ nhận tiền trên Layer2 của mình; sau khi giao dịch fund được đưa lên chuỗi, Alice có thể gửi dữ liệu giao dịch fund này đến hợp đồng cầu trên Layer2, chứng minh mình đã hoàn thành thao tác gửi tiền trên chuỗi Bitcoin, có đủ điều kiện để hợp đồng cầu L2 phát token cho địa chỉ nhận chỉ định.
Sau khi giao dịch fund được kích hoạt, tiền gửi thực tế vẫn bị khóa trong địa chỉ Taproot đa chữ ký do Alice và thành viên Liên minh BitVM cùng kiểm soát. Nhưng lưu ý rằng, địa chỉ đa chữ ký này chỉ có thể được mở khóa bằng CET, Liên minh BitVM không thể tùy tiện chuyển tiền đi.
Tiếp theo, chúng ta phân tích CET mà Alice và Liên minh BitVM xây dựng trước. Các CET này dùng để đáp ứng các kịch bản tiềm năng trong tương lai khi rút tiền, ví dụ Alice có thể gửi 1 BTC, nhưng lần rút đầu tiên chỉ rút 0,3 BTC, số còn lại 0,7 BTC giao cho quỹ công cộng của Liên minh BitVM quản lý, nhưng nếu muốn rút tiếp thì chỉ có thể dùng cầu BitVM đã nói ở trên;
Hoặc dùng luôn 0,7 BTC này khởi động một lần gửi tiền pre-fund mới, coi như tài sản mới nạp vào cầu DLC, có thể lặp lại quy trình giao dịch fund và xây dựng CET như đã nói.
Quy trình trên không khó hiểu, thực chất là để người gửi tiền Alice và Liên minh bitVM đóng vai trò đối thủ, 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 tạo trên Layer2, xác định Alice muốn kích hoạt CET nào (rút bao nhiêu tiền).
Rủi ro ở đây là oracle có thể cấu kết với Liên minh BitVM, ví dụ Alice tuyên bố muốn rút 0,5 BTC, nhưng oracle lại giả mạo tuyên bố rút tiền, cuối cùng khiến CET sai "Alice nhận 0,1 BTC, Liên minh BitVM nhận 0,9 BTC" được đưa lên chuỗi.
Có nhiều cách giải quyết vấn đề này, trước tiên là có thể dùng oracle bên thứ ba được thiết kế tốt, để ngăn hành vi cấu kết (khi đó, Liên minh BitVM rất khó móc nối với oracle), hoặc yêu cầu oracle đặt cược tài sản, oracle cần định kỳ công bố Cam kết (Commitment) trên chuỗi Bitcoin, tuyên bố xử lý trung thực yêu cầu rút tiền của người rút. Bất kỳ ai cũng có thể thách thức Cam kết này thông qua giao thức bằng chứng gian lận BitVM, nếu thách thức thành công, oracle làm điều ác sẽ bị phạt nặng (Slash).
Trong thiết kế cầu OP-DLC, người dùng luôn có thể "tham gia một tay" vào tài sản của mình, ngăn chặn Liên minh BitVM chiếm dụng, và loại thiết kế giống kênh này mang lại nhiều quyền tự chủ hơn cho người dùng, không cần trộn tiền của mình với tiền của người khác, giống như một phương án gửi/rút tiền điểm-điểm (P2P) hơn.
Hơn nữa, xét đến việc phương án BitVM cần một thời gian nữa mới triển khai được, trước khi đó, so với phương án đa chữ ký đơn thuần, cầu DLC là mô hình xử lý cầu nối đáng tin cậy hơn. Phương án này cũng có thể được dùng song song với cầu BitVM như hai cổng gửi/rút tiền, nếu một bên gặp sự cố, người dùng có thể dùng cổng còn lại, cũng là một phương pháp dự phòng lỗi tốt.
Tổng kết
Phương án cầu BitVM của BitLayer và Citrea bản chất là mô hình "ứng trước - hoàn trả", có nút Operator chuyên biệt chuyển tiền cho người rút, Operator có thể định kỳ xin hoàn tiền từ địa chỉ gửi tiền công cộng. Nếu đơn xin hoàn tiền của Operator không trung thực, bất kỳ ai cũng có thể thách thức và phạt nặng.
Phương án BitVM2 đưa vào chữ ký trước, kết hợp tư tưởng kênh, cho phép người dùng giới hạn quy trình xử lý sau khi gửi tiền trước khi chính thức gửi tiền, không cho tổ chức vận hành cầu chiếm dụng tiền gửi.
Loại cầu này về lý thuyết không có vấn đề an toàn, nhưng có vấn đề về tính sẵn sàng / khả dụng, đồng thời không đáp ứng được nhu cầu độc lập tài sản và chống rửa tiền của một số người dùng nhất định (bản chất vẫn là mô hình quỹ), độ khó triển khai cũng rất lớn.
Vì vậy, Bitlayer bổ sung thêm phương án cầu tên là OP-DLC, tương tự DLC.link, tích hợp thêm bằng chứng gian lận trên nền tảng kênh và DLC để ngăn chặn oracle của cầu DLC làm điều ác.
Nhưng do độ khó triển khai BitVM quá lớn, cầu DLC sẽ được triển khai trước và tạm thời trở thành giải pháp thay thế, chỉ cần giải quyết được rủi ro tin cậy của oracle, tích hợp oracle bên thứ ba đáng tin cậy và trưởng thành hơn, cầu DLC có thể trở thành phương án xác minh rút tiền an toàn hơn so với cầu đa chữ ký ở giai đoạn hiện tại.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
