Một người bạn của tôi từng cố giải thích escrow cho tôi bằng một phép ẩn dụ cái tủ khóa: bạn bỏ đồ của mình vào, người khác giữ chìa khóa, và bạn tin rằng họ sẽ trả lại khi họ nói sẽ trả. Tôi nói với anh ấy rằng tôi cũng hình dung mọi thiết lập crypto kiểu giám hộ (custodial) giống như vậy—một cái tủ khóa với ai đó đang cầm chìa khóa. So sánh đó với tôi không còn đứng vững nữa khi tôi lần theo cách các đường chi tiêu (spending paths) được tạo ra bên trong một Babylon vault, vì hóa ra là hoàn toàn không có một “cái chìa khóa” nào được giữ theo cách như tôi tưởng tượng. Người gửi tiền (depositor) đồng ký (co-sign) script của Bitcoin ngay từ đầu, tại thời điểm tạo vault, và mọi cách hợp lệ để BTC có thể được chuyển ra đều được tạo ra chữ ký vào tồn tại ngay lúc đó—được ký đồng thời bởi người gửi tiền và các thành viên tham gia của giao thức. Tôi biết được điều này sau khi đọc một chuỗi thảo luận từ <a>@BabylonLabs_io </a> đi từng bước qua việc xây dựng vault.
Không có “cửa phụ” nào được để dành cho sau này. Khi vault đã tồn tại, không ai—không phải giao thức, không phải một tập hợp validator, không phải một phiếu bầu quản trị trong tương lai—có thể tự ý nghĩ ra một điều kiện chi tiêu mới, vì tập chữ ký hợp lệ đã được cố định ngay từ đầu và không có gì sau đó có thể mở rộng nó. Phần dễ bị bỏ sót là đây không phải kiểu “giao thức hứa sẽ không lạm dụng quỹ”, mà là giao thức không có cơ chế để tạo một giao dịch nằm ngoài những gì đã được ký trước. Đó là một mô hình bảo mật khác với phần lớn các thiết lập bridge kiểu giám hộ hoặc multisig, nơi sự linh hoạt thường được giữ lại một cách có chủ ý để có thể điều chỉnh khóa hoặc ngưỡng sau khi triển khai—thuận tiện cho các bản nâng cấp—nhưng thường lại chính là “đường nối” (seam) mà cuối cùng bị khai thác.
Điều tôi vẫn chưa hình dung được là tính “cứng” đó sẽ đứng vững như thế nào trong những tình huống rối rắm hơn: điều kiện slashing kích hoạt, timelock hết hạn, tập hợp người tham gia xoay vòng trong suốt vòng đời của một vault. Không có đường mới nào xuất hiện, nhưng hệ thống vẫn cần thích nghi—cảm giác như hai thứ này sẽ mâu thuẫn. Vì vậy nguyên tắc thiết kế bản thân nó có vẻ hợp lý và thận trọng hơn mức tôi dự đoán, nhưng hành vi trong các tình huống biên (edge-case) thì <a>@BabylonLabs_io </a> vẫn chưa cho tôi thấy trong thực tế.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
An toàn của Vault phụ thuộc nhiều nhất vào ?
Không có “cửa phụ” nào được để dành cho sau này. Khi vault đã tồn tại, không ai—không phải giao thức, không phải một tập hợp validator, không phải một phiếu bầu quản trị trong tương lai—có thể tự ý nghĩ ra một điều kiện chi tiêu mới, vì tập chữ ký hợp lệ đã được cố định ngay từ đầu và không có gì sau đó có thể mở rộng nó. Phần dễ bị bỏ sót là đây không phải kiểu “giao thức hứa sẽ không lạm dụng quỹ”, mà là giao thức không có cơ chế để tạo một giao dịch nằm ngoài những gì đã được ký trước. Đó là một mô hình bảo mật khác với phần lớn các thiết lập bridge kiểu giám hộ hoặc multisig, nơi sự linh hoạt thường được giữ lại một cách có chủ ý để có thể điều chỉnh khóa hoặc ngưỡng sau khi triển khai—thuận tiện cho các bản nâng cấp—nhưng thường lại chính là “đường nối” (seam) mà cuối cùng bị khai thác.
Điều tôi vẫn chưa hình dung được là tính “cứng” đó sẽ đứng vững như thế nào trong những tình huống rối rắm hơn: điều kiện slashing kích hoạt, timelock hết hạn, tập hợp người tham gia xoay vòng trong suốt vòng đời của một vault. Không có đường mới nào xuất hiện, nhưng hệ thống vẫn cần thích nghi—cảm giác như hai thứ này sẽ mâu thuẫn. Vì vậy nguyên tắc thiết kế bản thân nó có vẻ hợp lý và thận trọng hơn mức tôi dự đoán, nhưng hành vi trong các tình huống biên (edge-case) thì <a>@BabylonLabs_io </a> vẫn chưa cho tôi thấy trong thực tế.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
An toàn của Vault phụ thuộc nhiều nhất vào ?
Fixed paths
50%
No side door
31%
Timelocks
13%
Edge case
6%
16 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
