@BabylonLabs_io
Tôi đang đọc phần whitepaper của Babylon về các đặc tính của vault thì có một cụm từ nhỏ đã khiến tôi dừng lại: "pre-set claimer". Lúc đầu, nó nghe giống như chỉ là một yêu cầu kỹ thuật — danh sách các bên được phép thực hiện việc claim và rút bitcoin phải được xác định ngay tại thời điểm vault được tạo. Nhưng càng suy nghĩ, tôi càng cảm thấy đó là một quyết định thiết kế kín đáo có thể thay đổi toàn bộ việc ai thậm chí có thể cố gắng chạm vào số tiền.
Điều đáng chú ý là nó thực sự loại trừ những gì. Không ai nằm ngoài tập hợp được định sẵn đó có thể nộp claim, dù với một bằng chứng tinh ranh hay một lỗ hổng kỹ thuật — vì vault đơn giản sẽ không nhận họ là đủ điều kiện. Nó khiến tôi nghĩ rằng điều này thu hẹp bề mặt tấn công ngay cả trước khi bất kỳ mật mã (cryptography) nào được đưa vào, gần như giống việc loại bỏ những cánh cửa dư thừa khỏi một tòa nhà thay vì chỉ lắp khóa tốt hơn cho các cửa hiện có.
Tuy vậy, tôi vẫn chưa chắc đây có hoàn toàn không đánh đổi gì. Việc khóa cứng tập hợp claimer ngay từ lúc tạo có nghĩa là về sau gần như không còn chỗ cho sự linh hoạt. Vậy nếu hoàn cảnh thay đổi, quan hệ cho vay phát triển, hoặc một khóa của claimer bị lộ/compromise ở chặng sau thì sao? Sự cứng nhắc giúp nó an toàn cũng khiến nó kém linh hoạt hơn so với các hệ thống cho phép cấp quyền động (dynamic permissioning) chăng?
Nhìn từ bên ngoài, nó giống như Babylon đã chọn tính dự đoán (predictability) hơn là khả năng thích ứng (adaptability), đặt cược rằng một bề mặt tấn công nhỏ hơn và cố định đáng giá hơn linh hoạt — thứ mà đa số người dùng có lẽ sẽ chẳng bao giờ cần. Liệu giả định đó có đúng khi các sản phẩm DeFi phức tạp hơn được xây dựng lên TBV hay không thì tôi chưa thể đánh giá hoàn toàn ngay lúc này. Có lẽ bài kiểm tra thật sự còn ở phía trước… dù sao thì thời gian sẽ trả lời 👍
$BROCCOLIF3B
$ON
$BABY
#baby
Tôi đang đọc phần whitepaper của Babylon về các đặc tính của vault thì có một cụm từ nhỏ đã khiến tôi dừng lại: "pre-set claimer". Lúc đầu, nó nghe giống như chỉ là một yêu cầu kỹ thuật — danh sách các bên được phép thực hiện việc claim và rút bitcoin phải được xác định ngay tại thời điểm vault được tạo. Nhưng càng suy nghĩ, tôi càng cảm thấy đó là một quyết định thiết kế kín đáo có thể thay đổi toàn bộ việc ai thậm chí có thể cố gắng chạm vào số tiền.
Điều đáng chú ý là nó thực sự loại trừ những gì. Không ai nằm ngoài tập hợp được định sẵn đó có thể nộp claim, dù với một bằng chứng tinh ranh hay một lỗ hổng kỹ thuật — vì vault đơn giản sẽ không nhận họ là đủ điều kiện. Nó khiến tôi nghĩ rằng điều này thu hẹp bề mặt tấn công ngay cả trước khi bất kỳ mật mã (cryptography) nào được đưa vào, gần như giống việc loại bỏ những cánh cửa dư thừa khỏi một tòa nhà thay vì chỉ lắp khóa tốt hơn cho các cửa hiện có.
Tuy vậy, tôi vẫn chưa chắc đây có hoàn toàn không đánh đổi gì. Việc khóa cứng tập hợp claimer ngay từ lúc tạo có nghĩa là về sau gần như không còn chỗ cho sự linh hoạt. Vậy nếu hoàn cảnh thay đổi, quan hệ cho vay phát triển, hoặc một khóa của claimer bị lộ/compromise ở chặng sau thì sao? Sự cứng nhắc giúp nó an toàn cũng khiến nó kém linh hoạt hơn so với các hệ thống cho phép cấp quyền động (dynamic permissioning) chăng?
Nhìn từ bên ngoài, nó giống như Babylon đã chọn tính dự đoán (predictability) hơn là khả năng thích ứng (adaptability), đặt cược rằng một bề mặt tấn công nhỏ hơn và cố định đáng giá hơn linh hoạt — thứ mà đa số người dùng có lẽ sẽ chẳng bao giờ cần. Liệu giả định đó có đúng khi các sản phẩm DeFi phức tạp hơn được xây dựng lên TBV hay không thì tôi chưa thể đánh giá hoàn toàn ngay lúc này. Có lẽ bài kiểm tra thật sự còn ở phía trước… dù sao thì thời gian sẽ trả lời 👍
$BROCCOLIF3B
$ON
$BABY
#baby