Bitcoin không thể đọc biên lai Ethereum, nhưng lại cần quyết định BTC được khóa trong Taproot nên trả về cho ai. Điều này giống như việc giao cho một quản vệ chỉ nhận con dấu, nhiệm vụ thẩm định một bản án của tòa án viết bằng ngoại ngữ.
Tôi lần theo quy trình BABE của @BabylonLabs_io để bóc tách tiếp, và phát hiện nó không phải là để Bitcoin Script chạy toàn bộ bộ xác minh ZK, mà là biến việc kiểm tra tính đúng/sai của chứng minh thành một trò thách thức được sắp đặt trước.
Khi chuộc lại, trước hết đường ống chứng minh sẽ xác nhận rằng khối trong vùng tín hiệu (beacon) của Ethereum đã được finality, rồi liên kết khối thực thi với biên lai chuộc lại, cuối cùng SP1 tạo ra chứng minh và nén thành Groth16. Bên nhận sẽ phát đi lệnh Claim và Assert; dùng WOTS để ghi cam kết của chứng minh vào giao dịch Bitcoin. Sau đó bước vào cửa sổ thách thức trên testnet công khai khoảng 432 khối BTC, gần ba ngày.
Điểm then chốt thực ra nằm ở Peg-in. Với các tham số hiện tại, mỗi nhóm bên nhận và người thách thức phải tạo ra 307 phiên bản mạch “lẫn lộn” (confusion circuit) ứng viên, công khai 301 phiên bản để kiểm tra gian lận, chỉ để lại 6 phiên bản được chọn ngẫu nhiên để xử lý các tranh chấp trong tương lai. Nói cách khác, trước tiên mở tung phần lớn tập đề niêm phong để kiểm hàng, phần còn lại mới dùng cho kỳ thi chính thức.
Nếu bên nhận nộp chứng minh giả, người thách thức sẽ phát lại để xác minh và khởi động Challenge; chứng minh giả không thể khôi phục đúng nhãn (label), thì sau khoảng 108 khối người thách thức có thể đi theo nhánh No-Payout, ngăn BTC được giải phóng và tịch thu khoản bảo đảm (bảo chứng) của kẻ gian. Nếu một chứng minh hợp lệ bị thách thức một cách ác ý, bên nhận lại có thể trích xuất đúng nhãn, phát đi WronglyChallenged để tiếp tục Payout, còn người thách thức sẽ mất khoản bảo đảm.
Vì vậy, BABE không phải để Bitcoin trực tiếp “hiểu” Ethereum, mà để kẻ nói dối không thể hoàn tất bước tiếp theo. Nhưng mạch lẫn lộn, đường ống chứng minh và tỷ lệ trực tuyến của người thách thức—chỉ cần sai ở bất kỳ mắt xích nào—đều có thể ảnh hưởng đến việc thoát khỏi rủi ro. Trước khi lên mainnet, thứ tôi muốn xem nhất là liệu một tranh chấp thực sự có thể chạy thông suốt hoàn chỉnh, chứ không chỉ là kịch bản Happy Path không bị ai thách thức.
#baby $BABY
Tôi lần theo quy trình BABE của @BabylonLabs_io để bóc tách tiếp, và phát hiện nó không phải là để Bitcoin Script chạy toàn bộ bộ xác minh ZK, mà là biến việc kiểm tra tính đúng/sai của chứng minh thành một trò thách thức được sắp đặt trước.
Khi chuộc lại, trước hết đường ống chứng minh sẽ xác nhận rằng khối trong vùng tín hiệu (beacon) của Ethereum đã được finality, rồi liên kết khối thực thi với biên lai chuộc lại, cuối cùng SP1 tạo ra chứng minh và nén thành Groth16. Bên nhận sẽ phát đi lệnh Claim và Assert; dùng WOTS để ghi cam kết của chứng minh vào giao dịch Bitcoin. Sau đó bước vào cửa sổ thách thức trên testnet công khai khoảng 432 khối BTC, gần ba ngày.
Điểm then chốt thực ra nằm ở Peg-in. Với các tham số hiện tại, mỗi nhóm bên nhận và người thách thức phải tạo ra 307 phiên bản mạch “lẫn lộn” (confusion circuit) ứng viên, công khai 301 phiên bản để kiểm tra gian lận, chỉ để lại 6 phiên bản được chọn ngẫu nhiên để xử lý các tranh chấp trong tương lai. Nói cách khác, trước tiên mở tung phần lớn tập đề niêm phong để kiểm hàng, phần còn lại mới dùng cho kỳ thi chính thức.
Nếu bên nhận nộp chứng minh giả, người thách thức sẽ phát lại để xác minh và khởi động Challenge; chứng minh giả không thể khôi phục đúng nhãn (label), thì sau khoảng 108 khối người thách thức có thể đi theo nhánh No-Payout, ngăn BTC được giải phóng và tịch thu khoản bảo đảm (bảo chứng) của kẻ gian. Nếu một chứng minh hợp lệ bị thách thức một cách ác ý, bên nhận lại có thể trích xuất đúng nhãn, phát đi WronglyChallenged để tiếp tục Payout, còn người thách thức sẽ mất khoản bảo đảm.
Vì vậy, BABE không phải để Bitcoin trực tiếp “hiểu” Ethereum, mà để kẻ nói dối không thể hoàn tất bước tiếp theo. Nhưng mạch lẫn lộn, đường ống chứng minh và tỷ lệ trực tuyến của người thách thức—chỉ cần sai ở bất kỳ mắt xích nào—đều có thể ảnh hưởng đến việc thoát khỏi rủi ro. Trước khi lên mainnet, thứ tôi muốn xem nhất là liệu một tranh chấp thực sự có thể chạy thông suốt hoàn chỉnh, chứ không chỉ là kịch bản Happy Path không bị ai thách thức.
#baby $BABY
