Có thể ngăn Payout, không có nghĩa là có thể viết lại hướng đi của BTC
Trong Trustless Bitcoin Vaults (TBV), Security Council rất dễ bị hiểu nhầm thành một nhóm multi-sig nắm quyền kiểm soát BTC. Testnet công khai hiện tại dùng 5 khóa Bitcoin công khai và cơ chế 3-of-5, trong đó các khóa công khai được ghi vào tham số giao thức ngoài chuỗi phiên bản hóa, để cùng ký CouncilNoPayout. Nó có thể ngăn Payout của một Vault nào đó, nhưng không thể chuyển BTC tới địa chỉ mới do Council chỉ định.
Giới hạn đến từ sơ đồ chi tiêu Bitcoin đã được cố định ngay từ lúc tạo Vault. Người gửi tiền đã ký trước Payout và xác định sẵn điểm đến hợp pháp: rút lui bình thường hoặc self-claim sẽ quay về địa chỉ của người gửi theo các điều kiện đã có sẵn, không cần Council phê duyệt; còn lộ trình thanh lý sẽ đi tới địa chỉ của đã được ủy quyền Application Vault Keeper. Các khóa của Council không nằm trong tập các điểm nhận này, nên dù đạt đủ định mức, nó chỉ có quyền chặn, chứ không có quyền chuyển hướng tài sản.
Điều này khác với No-Payout mà challenger phát đi trong quy trình tranh chấp thông thường: No-Payout đó dựa trên việc Claim vô hiệu bị thách thức và không thể phản chứng được. CouncilNoPayout được dùng cho các lỗi cực đoan hoặc cơ chế khôi phục đặc biệt mà cơ chế chuẩn không xử lý được. Còn pause ở phía Ethereum lại là một lớp khác: nó có thể tạm dừng thao tác ứng dụng, nhưng không thể viết lại các đường dẫn refund Pre-PegIn và WOTS self-claim đã tồn tại.
CouncilNoPayout đã thay đổi tiêu chuẩn đánh giá của tôi: tôi không còn chỉ hỏi trong hệ thống có tồn tại một ủy ban hay không, mà là nó có thể khiến Bitcoin chấp nhận những kết quả nào. Nếu chỉ có thể ngăn chi tiêu thì vẫn mang rủi ro về khả dụng và độ trễ khi rút lui; nếu không thể tạo điểm đến mới thì hậu quả tệ nhất được giới hạn ở mức chặn, chứ không phải chuyển hướng tài sản. Nếu quyền Council bị lạm dụng, các Payout hợp pháp vẫn có thể bị kẹt; nếu Council mất kết nối, năng lực khôi phục khẩn cũng sẽ giảm—không thể viết thiết kế này thành không có rủi ro.
@BabylonLabs_io định nghĩa Security Council như một lớp an toàn tạm thời, với mục tiêu dần dần ngừng sử dụng quyền lực của nó khi giao thức trưởng thành. Thứ đáng quan sát thực sự không phải việc liệu có multi-sig tồn tại hay không, mà là quyền khẩn cấp bị giới hạn ở bước nào trong các đường dẫn chi tiêu của Bitcoin.$BTC $ETH
$BABY
#baby
Trong Trustless Bitcoin Vaults (TBV), Security Council rất dễ bị hiểu nhầm thành một nhóm multi-sig nắm quyền kiểm soát BTC. Testnet công khai hiện tại dùng 5 khóa Bitcoin công khai và cơ chế 3-of-5, trong đó các khóa công khai được ghi vào tham số giao thức ngoài chuỗi phiên bản hóa, để cùng ký CouncilNoPayout. Nó có thể ngăn Payout của một Vault nào đó, nhưng không thể chuyển BTC tới địa chỉ mới do Council chỉ định.
Giới hạn đến từ sơ đồ chi tiêu Bitcoin đã được cố định ngay từ lúc tạo Vault. Người gửi tiền đã ký trước Payout và xác định sẵn điểm đến hợp pháp: rút lui bình thường hoặc self-claim sẽ quay về địa chỉ của người gửi theo các điều kiện đã có sẵn, không cần Council phê duyệt; còn lộ trình thanh lý sẽ đi tới địa chỉ của đã được ủy quyền Application Vault Keeper. Các khóa của Council không nằm trong tập các điểm nhận này, nên dù đạt đủ định mức, nó chỉ có quyền chặn, chứ không có quyền chuyển hướng tài sản.
Điều này khác với No-Payout mà challenger phát đi trong quy trình tranh chấp thông thường: No-Payout đó dựa trên việc Claim vô hiệu bị thách thức và không thể phản chứng được. CouncilNoPayout được dùng cho các lỗi cực đoan hoặc cơ chế khôi phục đặc biệt mà cơ chế chuẩn không xử lý được. Còn pause ở phía Ethereum lại là một lớp khác: nó có thể tạm dừng thao tác ứng dụng, nhưng không thể viết lại các đường dẫn refund Pre-PegIn và WOTS self-claim đã tồn tại.
CouncilNoPayout đã thay đổi tiêu chuẩn đánh giá của tôi: tôi không còn chỉ hỏi trong hệ thống có tồn tại một ủy ban hay không, mà là nó có thể khiến Bitcoin chấp nhận những kết quả nào. Nếu chỉ có thể ngăn chi tiêu thì vẫn mang rủi ro về khả dụng và độ trễ khi rút lui; nếu không thể tạo điểm đến mới thì hậu quả tệ nhất được giới hạn ở mức chặn, chứ không phải chuyển hướng tài sản. Nếu quyền Council bị lạm dụng, các Payout hợp pháp vẫn có thể bị kẹt; nếu Council mất kết nối, năng lực khôi phục khẩn cũng sẽ giảm—không thể viết thiết kế này thành không có rủi ro.
@BabylonLabs_io định nghĩa Security Council như một lớp an toàn tạm thời, với mục tiêu dần dần ngừng sử dụng quyền lực của nó khi giao thức trưởng thành. Thứ đáng quan sát thực sự không phải việc liệu có multi-sig tồn tại hay không, mà là quyền khẩn cấp bị giới hạn ở bước nào trong các đường dẫn chi tiêu của Bitcoin.$BTC $ETH
$BABY
#baby