Trình duyệt khối cho thấy đã có lệnh redeem, vậy $BTC vì sao vẫn chưa thể giải phóng?
Giao dịch Ethereum đã được phát tán, được đóng gói, sinh ra receipt, thậm chí còn có thể tra được redemption event—chỉ đủ để chứng minh rằng một execution block nào đó chứa bản ghi này. Đối với TBV của testnet công khai hiện tại, như vậy vẫn chưa đủ để giải phóng BTC, vì còn cần chứng minh rằng block đó thuộc về lịch sử cuối cùng mà Ethereum cuối cùng đã chấp nhận.
Người dùng tất toán nợ và withdraw Vault, hoặc quy trình thanh lý chuyển Vault cho vai trò redeem kế tiếp, đều sẽ kích hoạt redemption event. Bộ prover SP1 ngoài chuỗi sẽ xây dựng chứng minh theo một thứ tự cố định: Beacon finality trước tiên xác nhận rằng beacon block đã được lớp đồng thuận finalize; Execution finality sau đó nối beacon block đã finalized này với execution block chứa giao dịch redeem; Receipt inclusion cuối cùng xác nhận rằng redemption log mục tiêu tồn tại trong transaction receipt của block đó. Groth16 chỉ nén và tổng hợp các chứng minh của ba lớp đầu thành một proof gọn nhẹ, và không trao tính cuối cùng (finality) cho block.
Bộ phân tầng này đã thay đổi nhận định của tôi: tôi không còn xem “trình duyệt đã nhìn thấy giao dịch” như việc thực tế cross-chain redeem đã thành. Thay vào đó, tôi sẽ kiểm tra xem có thể đồng thời chứng minh được hai điều—sự kiện thực sự đã được bao gồm, và execution block mang nó cũng đã được beacon chain finality lớp đồng thuận của Ethereum công nhận. Lớp trước trả lời “đã xảy ra gì”, còn lớp sau trả lời “nó có trở thành trạng thái cuối cùng của Ethereum hay không”. Thiếu lớp sau, Bitcoin Payout có thể được thiết lập dựa trên lịch sử bên ngoài chưa ổn định.
Sau khi hoàn tất chứng minh finality và inclusion, claimer mới đưa proof nén đó vào Claim bên phía Bitcoin, Assert và cửa sổ challenge. Finality của Ethereum xác nhận sự kiện bên ngoài thuộc đoạn lịch sử cuối cùng nào; cửa sổ challenge của Bitcoin kiểm tra liệu proof được nộp sang phía Bitcoin có thể được chứng minh là hợp lệ hay không. Hai bên không phải là cùng một đoạn chờ, cũng không thể thay thế lẫn nhau; chỉ khi proof không bị lật đổ hiệu lực, Payout mới đi vào thực thi.
Cũng cần làm rõ ranh giới: chứng minh finalized redemption event chỉ cho thấy log đó đã đi vào trạng thái cuối cùng của Ethereum, chứ không đồng nghĩa với việc hợp đồng upstream, oracle hoặc phán quyết thanh lý chắc chắn là kinh tế đúng. Nếu lớp đồng thuận của Ethereum gặp lỗi sâu, việc xác minh cũng có thể bị đình trệ hoặc sai. @BabylonLabs_io đặt ngưỡng ở “sự kiện trong lịch sử cuối cùng”, chứ không phải “sự kiện mà trình duyệt nhìn thấy”, chính vì sau khi Bitcoin phát hành thì sẽ không tự động rút lại Payout do thay đổi tiếp theo của chuỗi bên ngoài. $ETH
$BABY
#baby
Giao dịch Ethereum đã được phát tán, được đóng gói, sinh ra receipt, thậm chí còn có thể tra được redemption event—chỉ đủ để chứng minh rằng một execution block nào đó chứa bản ghi này. Đối với TBV của testnet công khai hiện tại, như vậy vẫn chưa đủ để giải phóng BTC, vì còn cần chứng minh rằng block đó thuộc về lịch sử cuối cùng mà Ethereum cuối cùng đã chấp nhận.
Người dùng tất toán nợ và withdraw Vault, hoặc quy trình thanh lý chuyển Vault cho vai trò redeem kế tiếp, đều sẽ kích hoạt redemption event. Bộ prover SP1 ngoài chuỗi sẽ xây dựng chứng minh theo một thứ tự cố định: Beacon finality trước tiên xác nhận rằng beacon block đã được lớp đồng thuận finalize; Execution finality sau đó nối beacon block đã finalized này với execution block chứa giao dịch redeem; Receipt inclusion cuối cùng xác nhận rằng redemption log mục tiêu tồn tại trong transaction receipt của block đó. Groth16 chỉ nén và tổng hợp các chứng minh của ba lớp đầu thành một proof gọn nhẹ, và không trao tính cuối cùng (finality) cho block.
Bộ phân tầng này đã thay đổi nhận định của tôi: tôi không còn xem “trình duyệt đã nhìn thấy giao dịch” như việc thực tế cross-chain redeem đã thành. Thay vào đó, tôi sẽ kiểm tra xem có thể đồng thời chứng minh được hai điều—sự kiện thực sự đã được bao gồm, và execution block mang nó cũng đã được beacon chain finality lớp đồng thuận của Ethereum công nhận. Lớp trước trả lời “đã xảy ra gì”, còn lớp sau trả lời “nó có trở thành trạng thái cuối cùng của Ethereum hay không”. Thiếu lớp sau, Bitcoin Payout có thể được thiết lập dựa trên lịch sử bên ngoài chưa ổn định.
Sau khi hoàn tất chứng minh finality và inclusion, claimer mới đưa proof nén đó vào Claim bên phía Bitcoin, Assert và cửa sổ challenge. Finality của Ethereum xác nhận sự kiện bên ngoài thuộc đoạn lịch sử cuối cùng nào; cửa sổ challenge của Bitcoin kiểm tra liệu proof được nộp sang phía Bitcoin có thể được chứng minh là hợp lệ hay không. Hai bên không phải là cùng một đoạn chờ, cũng không thể thay thế lẫn nhau; chỉ khi proof không bị lật đổ hiệu lực, Payout mới đi vào thực thi.
Cũng cần làm rõ ranh giới: chứng minh finalized redemption event chỉ cho thấy log đó đã đi vào trạng thái cuối cùng của Ethereum, chứ không đồng nghĩa với việc hợp đồng upstream, oracle hoặc phán quyết thanh lý chắc chắn là kinh tế đúng. Nếu lớp đồng thuận của Ethereum gặp lỗi sâu, việc xác minh cũng có thể bị đình trệ hoặc sai. @BabylonLabs_io đặt ngưỡng ở “sự kiện trong lịch sử cuối cùng”, chứ không phải “sự kiện mà trình duyệt nhìn thấy”, chính vì sau khi Bitcoin phát hành thì sẽ không tự động rút lại Payout do thay đổi tiếp theo của chuỗi bên ngoài. $ETH
$BABY
#baby