Nova_eth_20
422 Bài đăng
Nova_eth_20
129 Đang theo dõi
1.5K+ Người theo dõi
450 Đã thích
Bài đăng
Tất cả
Trích dẫn
Xem bản dịch
#baby $BABY @BabylonLabs_io
Was comparing validators for my BABY delegation and almost skipped past "jailing" as the standard Cosmos boilerplate every chain has, missed blocks, temporary timeout, nothing specific to Babylon. Then I read what validators actually sign twice, not once.
Every Babylon Genesis validator does two separate jobs. Regular CometBFT block signing, the ordinary work any Cosmos validator does, and a second one: BLS voting at the end of each epoch, where validator signatures get aggregated into a checkpoint that's timestamped directly onto Bitcoin. That second signature is the entire reason people call this chain Bitcoin-secured.
Downtime jailing only cares about the first job, on its own terms, standard liveness enforcement, nothing dramatic. What I couldn't pin down precisely is the exact interaction, whether a jailing that lands mid-epoch quietly disqualifies that whole epoch's BLS contribution, or only matters if it's still active the moment the epoch closes. Babylon's docs confirm the two jobs are separate. They don't spell out that specific timing boundary anywhere I found.
Either way, the two jobs share one uptime record. A validator jailed for ordinary missed blocks, the same rule any Cosmos chain runs, isn't protected from also missing the signature that actually gets anchored to Bitcoin that epoch, for a reason that has nothing to do with Bitcoin security at all.
I don't think this is a design flaw, there's no clean way to jail someone from one role and not the other on the same key. What I hadn't separated in my head before this was that downtime history isn't just about missed rewards. It's a rough proxy for how often a validator was actually present for the signature that makes "Bitcoin-secured" true.
Checked my shortlist's jailing history again. Two names had one entry each, both over a year old, both followed by long clean stretches since. Not a red flag. Just not the same zero I'd assumed a clean uptime percentage was already telling me.
$BLESS
🤔 What's the first thing you check before delegating your baby
Was comparing validators for my BABY delegation and almost skipped past "jailing" as the standard Cosmos boilerplate every chain has, missed blocks, temporary timeout, nothing specific to Babylon. Then I read what validators actually sign twice, not once.
Every Babylon Genesis validator does two separate jobs. Regular CometBFT block signing, the ordinary work any Cosmos validator does, and a second one: BLS voting at the end of each epoch, where validator signatures get aggregated into a checkpoint that's timestamped directly onto Bitcoin. That second signature is the entire reason people call this chain Bitcoin-secured.
Downtime jailing only cares about the first job, on its own terms, standard liveness enforcement, nothing dramatic. What I couldn't pin down precisely is the exact interaction, whether a jailing that lands mid-epoch quietly disqualifies that whole epoch's BLS contribution, or only matters if it's still active the moment the epoch closes. Babylon's docs confirm the two jobs are separate. They don't spell out that specific timing boundary anywhere I found.
Either way, the two jobs share one uptime record. A validator jailed for ordinary missed blocks, the same rule any Cosmos chain runs, isn't protected from also missing the signature that actually gets anchored to Bitcoin that epoch, for a reason that has nothing to do with Bitcoin security at all.
I don't think this is a design flaw, there's no clean way to jail someone from one role and not the other on the same key. What I hadn't separated in my head before this was that downtime history isn't just about missed rewards. It's a rough proxy for how often a validator was actually present for the signature that makes "Bitcoin-secured" true.
Checked my shortlist's jailing history again. Two names had one entry each, both over a year old, both followed by long clean stretches since. Not a red flag. Just not the same zero I'd assumed a clean uptime percentage was already telling me.
$BLESS
🤔 What's the first thing you check before delegating your baby
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Tôi đã chọn một nhà cung cấp finality dựa trên quy mô ủy thác BTC của họ và lịch sử uptime—những con số mà mọi bảng điều khiển đều hiển thị. Chỉ sau đó tôi mới đọc xem điều gì thực sự giữ cho nhà cung cấp đó hoạt động từng ngày, và hóa ra không hề liên quan đến BTC.
Mỗi nhà cung cấp finality đều cần một khóa vận hành riêng được cấp vốn bằng BABY, với các khoản nhỏ, dùng để trả phí gas cho việc cam kết ngẫu nhiên mới theo một lịch trình lặp lại. Các lần gửi vote sẽ được hoàn lại tự động—tài liệu hướng dẫn riêng của Babylon xác nhận điều này một cách trực tiếp. Các giao dịch khác trên cùng khóa đó, bao gồm cả các cam kết ngẫu nhiên lặp lại, lại cần gas mà không được hoàn lại. Tài liệu mô tả nó gần như như một chi tiết sau cùng: hãy cấp vốn với mức tối thiểu, giữ cho nó chạy trong thời gian dài, chỉ một câu nằm bên cạnh “bộ máy” bảo mật mà thực sự tôi đã đi tìm.
Nếu bạn bỏ lỡ lần nạp lại đó, nhà cung cấp sẽ không bị bí mật bị xâm phạm—ủy thác BTC của họ vẫn lớn và trung thực y như hôm qua. Họ chỉ đơn giản là không thể tiếp tục tham gia cho đến khi ai đó nhận ra ví trống và nạp thêm. Một nhà cung cấp có thể hoàn hảo trên mọi chỉ số mà tôi đã kiểm tra trước khi ủy thác, nhưng vẫn có thể “tắt ngấm” vì một thứ nhỏ bé như một khóa gas mà chẳng ai nhớ phải nạp lại.
Các bảng điều khiển về ủy thác hiển thị hoa hồng, quy mô ủy thác, và lịch sử uptime. Không bảng nào cho thấy liệu khóa vận hành của nhà cung cấp có được cấp vốn “thoải mái” hay đang chạy trên “cạn kiệt”, vì con số đó vốn không được thiết kế để công khai ngay từ đầu.
Tôi không nghĩ đây là một lỗi trong thiết kế: việc giữ khóa vận hành ở mức tối thiểu và tách khỏi số tài sản thực sự của nhà cung cấp là một lựa chọn bảo mật hợp lý, không phải sự cẩu thả. Điều đó có ý nghĩa gì với bất kỳ ai ủy thác? Ít hơn một chút: nhà cung cấp bạn chọn dựa trên thành tích BTC của họ cũng, một cách lặng lẽ, đang làm công việc… nhớ mua gas.
$HEI
Bạn có biết rằng khóa vận hành của một nhà cung cấp finality có thể cạn gas ngay cả khi phần ủy thác BTC của họ trông vẫn hoàn toàn khỏe mạnh không?
Tôi đã chọn một nhà cung cấp finality dựa trên quy mô ủy thác BTC của họ và lịch sử uptime—những con số mà mọi bảng điều khiển đều hiển thị. Chỉ sau đó tôi mới đọc xem điều gì thực sự giữ cho nhà cung cấp đó hoạt động từng ngày, và hóa ra không hề liên quan đến BTC.
Mỗi nhà cung cấp finality đều cần một khóa vận hành riêng được cấp vốn bằng BABY, với các khoản nhỏ, dùng để trả phí gas cho việc cam kết ngẫu nhiên mới theo một lịch trình lặp lại. Các lần gửi vote sẽ được hoàn lại tự động—tài liệu hướng dẫn riêng của Babylon xác nhận điều này một cách trực tiếp. Các giao dịch khác trên cùng khóa đó, bao gồm cả các cam kết ngẫu nhiên lặp lại, lại cần gas mà không được hoàn lại. Tài liệu mô tả nó gần như như một chi tiết sau cùng: hãy cấp vốn với mức tối thiểu, giữ cho nó chạy trong thời gian dài, chỉ một câu nằm bên cạnh “bộ máy” bảo mật mà thực sự tôi đã đi tìm.
Nếu bạn bỏ lỡ lần nạp lại đó, nhà cung cấp sẽ không bị bí mật bị xâm phạm—ủy thác BTC của họ vẫn lớn và trung thực y như hôm qua. Họ chỉ đơn giản là không thể tiếp tục tham gia cho đến khi ai đó nhận ra ví trống và nạp thêm. Một nhà cung cấp có thể hoàn hảo trên mọi chỉ số mà tôi đã kiểm tra trước khi ủy thác, nhưng vẫn có thể “tắt ngấm” vì một thứ nhỏ bé như một khóa gas mà chẳng ai nhớ phải nạp lại.
Các bảng điều khiển về ủy thác hiển thị hoa hồng, quy mô ủy thác, và lịch sử uptime. Không bảng nào cho thấy liệu khóa vận hành của nhà cung cấp có được cấp vốn “thoải mái” hay đang chạy trên “cạn kiệt”, vì con số đó vốn không được thiết kế để công khai ngay từ đầu.
Tôi không nghĩ đây là một lỗi trong thiết kế: việc giữ khóa vận hành ở mức tối thiểu và tách khỏi số tài sản thực sự của nhà cung cấp là một lựa chọn bảo mật hợp lý, không phải sự cẩu thả. Điều đó có ý nghĩa gì với bất kỳ ai ủy thác? Ít hơn một chút: nhà cung cấp bạn chọn dựa trên thành tích BTC của họ cũng, một cách lặng lẽ, đang làm công việc… nhớ mua gas.
$HEI
Bạn có biết rằng khóa vận hành của một nhà cung cấp finality có thể cạn gas ngay cả khi phần ủy thác BTC của họ trông vẫn hoàn toàn khỏe mạnh không?
#baby @BabylonLabs_io
Đêm qua tôi đọc được một bản phân tích về việc cắt phạt (slashing) khi đi săn con số phạt chính xác của BTC. Tìm thấy rồi: 0,1% BTC đã đặt (staked) cho hành vi ký kép (double-signing). Sau đó lại thấy một dòng nằm ngay bên cạnh mà tôi không để ý tới: phần thưởng đã nhận trước đó không bị thu hồi.
Nhà cung cấp sẽ bị cấm vĩnh viễn, bị tống giam mãi mãi, không còn ủy quyền nữa, không còn hoa hồng nữa. Nhưng bất kỳ khoản hoa hồng nào họ đã thu trước khi vi phạm thì vẫn thuộc về họ. Mức phạt sẽ chạy tiếp từ thời điểm họ bị bắt. Nó không quay ngược trở lại để tính trong khoảng thời gian họ đã hoạt động trước đó bao lâu.
Với một nhà cung cấp mới toanh, khoảng trống này gần như chẳng đáng kể vì chưa có gì tích lũy để thu hồi. Nhưng với một người đã chạy ủy quyền được một năm, kiếm một phần hoa hồng cắt trên mỗi chu kỳ nhận thưởng suốt thời gian đó, thì phép tính sẽ khác. Chỉ một lần cắt 0,1% sẽ ảnh hưởng đến tất cả những người đã ủy quyền cho họ, theo tỉ lệ—cả nhà cung cấp và người ủy quyền. Còn thứ không bị đụng tới chính là lịch sử hoa hồng, dù họ đã rời đi với số tiền lớn đến mức nào.
Tôi không biết chính xác mỗi nhà cung cấp cá nhân đã kiếm được bao nhiêu trong suốt thời gian họ làm việc—thông tin đó không công khai ở bất kỳ nơi nào tôi tìm thấy—nên tôi không thể nói với bạn rằng khoảng trống này là không đáng kể hay là có thực. Điều tôi có thể nói là cơ chế răn đe đã được cố ý thiết kế theo hướng chỉ áp dụng cho tương lai. Việc thu hồi phần thưởng lịch sử sẽ đồng nghĩa phải mở lại từng chu kỳ nhận thưởng trong quá khứ—một mớ hỗn độn để phải thiết kế và xử lý.
Bị cấm vĩnh viễn và bị phá sản là hai kết cục khác nhau, và thiết kế slashing của Babylon chỉ đảm bảo được kết cục đầu tiên.
$CYS $BABY
Đêm qua tôi đọc được một bản phân tích về việc cắt phạt (slashing) khi đi săn con số phạt chính xác của BTC. Tìm thấy rồi: 0,1% BTC đã đặt (staked) cho hành vi ký kép (double-signing). Sau đó lại thấy một dòng nằm ngay bên cạnh mà tôi không để ý tới: phần thưởng đã nhận trước đó không bị thu hồi.
Nhà cung cấp sẽ bị cấm vĩnh viễn, bị tống giam mãi mãi, không còn ủy quyền nữa, không còn hoa hồng nữa. Nhưng bất kỳ khoản hoa hồng nào họ đã thu trước khi vi phạm thì vẫn thuộc về họ. Mức phạt sẽ chạy tiếp từ thời điểm họ bị bắt. Nó không quay ngược trở lại để tính trong khoảng thời gian họ đã hoạt động trước đó bao lâu.
Với một nhà cung cấp mới toanh, khoảng trống này gần như chẳng đáng kể vì chưa có gì tích lũy để thu hồi. Nhưng với một người đã chạy ủy quyền được một năm, kiếm một phần hoa hồng cắt trên mỗi chu kỳ nhận thưởng suốt thời gian đó, thì phép tính sẽ khác. Chỉ một lần cắt 0,1% sẽ ảnh hưởng đến tất cả những người đã ủy quyền cho họ, theo tỉ lệ—cả nhà cung cấp và người ủy quyền. Còn thứ không bị đụng tới chính là lịch sử hoa hồng, dù họ đã rời đi với số tiền lớn đến mức nào.
Tôi không biết chính xác mỗi nhà cung cấp cá nhân đã kiếm được bao nhiêu trong suốt thời gian họ làm việc—thông tin đó không công khai ở bất kỳ nơi nào tôi tìm thấy—nên tôi không thể nói với bạn rằng khoảng trống này là không đáng kể hay là có thực. Điều tôi có thể nói là cơ chế răn đe đã được cố ý thiết kế theo hướng chỉ áp dụng cho tương lai. Việc thu hồi phần thưởng lịch sử sẽ đồng nghĩa phải mở lại từng chu kỳ nhận thưởng trong quá khứ—một mớ hỗn độn để phải thiết kế và xử lý.
Bị cấm vĩnh viễn và bị phá sản là hai kết cục khác nhau, và thiết kế slashing của Babylon chỉ đảm bảo được kết cục đầu tiên.
$CYS $BABY
Xem bản dịch
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Hôm qua đêm tôi đã kiểm tra hoa hồng của một nhà cung cấp tính cuối kỳ trước khi ủy quyền, 5%, trông có vẻ hợp lý khi so với những nhà khác trong danh sách. Gần như tôi đã ủy quyền chỉ dựa vào con số đó. Rồi tôi phát hiện ra lệnh đăng ký mà Babylon thực sự yêu cầu phía sau nó.
Mỗi nhà cung cấp tính cuối kỳ khi đăng ký sẽ đặt ba con số, không phải một. Tỷ lệ hoa hồng hiện tại, một tỷ lệ tối đa mà nó không bao giờ được vượt quá, và một tỷ lệ thay đổi tối đa—mức độ nhanh mà nó được phép leo lên tiến gần đến ngưỡng đó. Cái 5% mà tôi nhìn thấy không bao giờ là toàn bộ bức tranh; nó chỉ là một khoảnh khắc trên một “bánh xe” có điểm dừng riêng cao hơn, được gài sẵn ngay từ ngày đầu.
Không có gì ngăn một nhà cung cấp đăng ký ở mức 5% với mức tối đa 50%, rồi tăng nó theo từng bước hợp pháp nhỏ trong mỗi kỳ cho đến khi những người đã gia nhập ở mức 5% nhận được lợi nhuận dưới một con số hoàn toàn khác. Không vi phạm quy định nào, không có gì “giật lùi”, chỉ là một trần đã được công khai từ suốt thời gian đó.
Tôi đi tìm xem cái “trần” ấy thực sự xuất hiện ở đâu khi một người ủy quyền quyết định chọn ai. Theo những gì tôi có thể tìm được, tài liệu staking của chính Babylon và API cung cấp dữ liệu cho bảng điều khiển chỉ thể hiện đúng một trường tại giai đoạn đó: commission. Thấp hơn nghĩa là phần thưởng cao hơn—và không có chi tiết hơn. Không phải là mức max rate nằm ở ô kế bên trong dữ liệu đăng ký riêng của nhà cung cấp.
Tôi không nghĩ cơ chế này mang tính “săn mồi”. Giới hạn theo tốc độ thay đổi tồn tại chính xác để hoa hồng không thể nhảy vọt qua đêm, và cơ chế bảo vệ đó là có thật. Thứ còn thiếu là nhỏ hơn: con số thực sự giới hạn thu nhập tương lai của bạn không được thiết kế để hiển thị trên màn hình mà bạn đang quyết định từ đó. Tài liệu không nói có bao nhiêu nhà cung cấp hoạt động đã rời khỏi mức khởi đầu của họ, hoặc hiện tại bất kỳ nhà nào trong số họ đang cách trần của mình bao xa, nên tôi không thể cho bạn biết đây là rủi ro “đang xảy ra” hay chỉ là rủi ro mang tính lý thuyết.
Mức 5% bạn thấy chỉ là một tấm ảnh. Cái trần luôn luôn là thỏa thuận thực sự.
Bạn có biết hoa hồng của nhà cung cấp tính cuối kỳ của bạn có thể tăng vượt qua con số bạn thấy hôm nay không? 📈
Hôm qua đêm tôi đã kiểm tra hoa hồng của một nhà cung cấp tính cuối kỳ trước khi ủy quyền, 5%, trông có vẻ hợp lý khi so với những nhà khác trong danh sách. Gần như tôi đã ủy quyền chỉ dựa vào con số đó. Rồi tôi phát hiện ra lệnh đăng ký mà Babylon thực sự yêu cầu phía sau nó.
Mỗi nhà cung cấp tính cuối kỳ khi đăng ký sẽ đặt ba con số, không phải một. Tỷ lệ hoa hồng hiện tại, một tỷ lệ tối đa mà nó không bao giờ được vượt quá, và một tỷ lệ thay đổi tối đa—mức độ nhanh mà nó được phép leo lên tiến gần đến ngưỡng đó. Cái 5% mà tôi nhìn thấy không bao giờ là toàn bộ bức tranh; nó chỉ là một khoảnh khắc trên một “bánh xe” có điểm dừng riêng cao hơn, được gài sẵn ngay từ ngày đầu.
Không có gì ngăn một nhà cung cấp đăng ký ở mức 5% với mức tối đa 50%, rồi tăng nó theo từng bước hợp pháp nhỏ trong mỗi kỳ cho đến khi những người đã gia nhập ở mức 5% nhận được lợi nhuận dưới một con số hoàn toàn khác. Không vi phạm quy định nào, không có gì “giật lùi”, chỉ là một trần đã được công khai từ suốt thời gian đó.
Tôi đi tìm xem cái “trần” ấy thực sự xuất hiện ở đâu khi một người ủy quyền quyết định chọn ai. Theo những gì tôi có thể tìm được, tài liệu staking của chính Babylon và API cung cấp dữ liệu cho bảng điều khiển chỉ thể hiện đúng một trường tại giai đoạn đó: commission. Thấp hơn nghĩa là phần thưởng cao hơn—và không có chi tiết hơn. Không phải là mức max rate nằm ở ô kế bên trong dữ liệu đăng ký riêng của nhà cung cấp.
Tôi không nghĩ cơ chế này mang tính “săn mồi”. Giới hạn theo tốc độ thay đổi tồn tại chính xác để hoa hồng không thể nhảy vọt qua đêm, và cơ chế bảo vệ đó là có thật. Thứ còn thiếu là nhỏ hơn: con số thực sự giới hạn thu nhập tương lai của bạn không được thiết kế để hiển thị trên màn hình mà bạn đang quyết định từ đó. Tài liệu không nói có bao nhiêu nhà cung cấp hoạt động đã rời khỏi mức khởi đầu của họ, hoặc hiện tại bất kỳ nhà nào trong số họ đang cách trần của mình bao xa, nên tôi không thể cho bạn biết đây là rủi ro “đang xảy ra” hay chỉ là rủi ro mang tính lý thuyết.
Mức 5% bạn thấy chỉ là một tấm ảnh. Cái trần luôn luôn là thỏa thuận thực sự.
Bạn có biết hoa hồng của nhà cung cấp tính cuối kỳ của bạn có thể tăng vượt qua con số bạn thấy hôm nay không? 📈
Xem bản dịch
#baby @BabylonLabs_io
I have BTC staked through Babylon right now, so when I found the word "overflow" buried in old Cap-3 documentation last night, I didn't read it as history. I read it as a question about my own position: could this happen to me.
During Phase 1, staking transactions that confirmed after the cap already filled still locked the BTC into the contract exactly like everyone else's. They just earned nothing, no points, no allocation. Getting the coins back wasn't automatic either, the docs are explicit: overflow stakes still had to be unbonded and withdrawn, same wait as an active position, for a stake that paid zero the entire time it sat locked.
What decided who made it in wasn't when anyone clicked stake. It was which Bitcoin block the transaction actually confirmed in, a number nobody fully controls once it leaves the wallet. Two people could broadcast minutes apart and land in either order depending on fees, mempool congestion, or which miner found the next block first.
Phase 1's caps are gone, but the mechanism that created overflow isn't unique to that phase. Any future capped round, a new BSN onboarding with a fixed allocation, a limited-slot integration, inherits the same race the moment it uses block confirmations instead of a queue. Nothing about that design flaw was patched. It was just outgrown when the caps disappeared.
I don't think the original design was unfair, a hard cap needs some cutoff, and block confirmation can't be faked the way a timestamp can. What stays with me is smaller: my own BTC sitting locked right now was never protected by skill or good timing. It cleared a line drawn by miners, not by me, and next time that line gets drawn, it still will be.
$SKYAI $BICO $BABY
"Would this overflow risk stop you from staking in a future capped round?" 🎯
I have BTC staked through Babylon right now, so when I found the word "overflow" buried in old Cap-3 documentation last night, I didn't read it as history. I read it as a question about my own position: could this happen to me.
During Phase 1, staking transactions that confirmed after the cap already filled still locked the BTC into the contract exactly like everyone else's. They just earned nothing, no points, no allocation. Getting the coins back wasn't automatic either, the docs are explicit: overflow stakes still had to be unbonded and withdrawn, same wait as an active position, for a stake that paid zero the entire time it sat locked.
What decided who made it in wasn't when anyone clicked stake. It was which Bitcoin block the transaction actually confirmed in, a number nobody fully controls once it leaves the wallet. Two people could broadcast minutes apart and land in either order depending on fees, mempool congestion, or which miner found the next block first.
Phase 1's caps are gone, but the mechanism that created overflow isn't unique to that phase. Any future capped round, a new BSN onboarding with a fixed allocation, a limited-slot integration, inherits the same race the moment it uses block confirmations instead of a queue. Nothing about that design flaw was patched. It was just outgrown when the caps disappeared.
I don't think the original design was unfair, a hard cap needs some cutoff, and block confirmation can't be faked the way a timestamp can. What stays with me is smaller: my own BTC sitting locked right now was never protected by skill or good timing. It cleared a line drawn by miners, not by me, and next time that line gets drawn, it still will be.
$SKYAI $BICO $BABY
"Would this overflow risk stop you from staking in a future capped round?" 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Tôi đã chốt tỷ lệ đồng-stake (co-staking) của mình cách đây ba tuần — 20.000 BABY cho mỗi BTC, đúng theo tỷ lệ mà Babylon khuyến nghị. Tối qua tôi kiểm tra phần thưởng của mình. Thấp hơn con số tôi đã tính vào ngày tôi stake.
Vị trí của tôi không hề dịch chuyển. Nhưng thứ khác thì có.
Mức boost đồng-staking 2,35% này không phải là một “lãi suất”. Đó là một quỹ có kích thước cố định, được chia tỷ lệ cho mọi ví tham gia đồng-staking ngay tại thời điểm đó. Babylon nói điều này rất rõ trong tài liệu của họ: có nhiều đồng-staker hơn thì phần thưởng cá nhân sẽ nhỏ hơn. Khớp tỷ lệ hoàn hảo, phần chia thực của bạn vẫn phụ thuộc vào việc có bao nhiêu ví khác cũng khớp tỷ lệ đó—một con số thay đổi dù bạn không hề chạm vào vị trí của mình.
Không có dashboard nào theo dõi con số này theo thời gian thực. Bạn có thể xem “weight” (trọng số) của riêng mình. Bạn không thể thấy tổng trọng số của cả quỹ đang thay đổi bên dưới.
Khác với các rủi ro Babylon khác vốn có thể ẩn trong hạ tầng thiếu hoàn chỉnh hoặc do các nhà vận hành tập trung, rủi ro này lại hiện hữu ngay trước mắt — công thức hoàn toàn công khai. Thứ duy nhất thiếu là biết còn ai khác đang sử dụng nó.
Một điều đáng theo dõi: 2,35% này không phải nền tảng vững như đá tảng, mà là một con số do quản trị (governance) quyết định. Nó chỉ tồn tại vì một đề xuất hồi tháng 9 năm ngoái đã cắt “lạm phát” của Babylon thành các lát cố định: 1% cho người stake BTC, 2% cho người stake BABY, 2,35% cho co-stakers, phần còn lại chia ở nơi khác. Một cuộc bỏ phiếu trong tương lai có thể thay đổi kích thước lát đó theo cách tương tự như lần này đã tạo ra nó. Chưa có ai đề xuất thu hẹp nó, nên đây vẫn là một chỗ ngồi bạn phải theo dõi, chứ không phải là bàn bạn chắc chắn sẽ được giữ.
Có một “cạnh” (edge) thứ hai được gài sẵn trong công thức. Trọng số đủ điều kiện bị giới hạn ở mức nhỏ hơn trong hai giá trị: BABY của bạn chia cho 20.000, hoặc BTC của bạn. Vượt tỷ lệ và phần BABY dư chỉ nhận được đúng lãi suất staking thông thường. Chưa đạt tỷ lệ và chỉ một phần BTC của bạn được hưởng mức boost.
Việc ghép BTC và BABY được xây dựng để củng cố mối liên kết đó, và một quỹ dùng chung là cách hợp lý để tài trợ cho nó. Thiết kế không phải vấn đề. Vấn đề nằm ở chỗ bạn không thể nhìn thấy phần chia của mình sẽ dịch chuyển ra sao trước khi nó xảy ra.
Nếu bạn đã khớp tỷ lệ đúng như tôi đã làm, bạn không nhận được một mức 2,35% cố định. Bạn đang thuê một chỗ ngồi tại một cái bàn mà sẽ ngày càng đông người theo lịch của chính nó—bởi những người bạn sẽ không bao giờ thấy họ đến.
Tôi đã chốt tỷ lệ đồng-stake (co-staking) của mình cách đây ba tuần — 20.000 BABY cho mỗi BTC, đúng theo tỷ lệ mà Babylon khuyến nghị. Tối qua tôi kiểm tra phần thưởng của mình. Thấp hơn con số tôi đã tính vào ngày tôi stake.
Vị trí của tôi không hề dịch chuyển. Nhưng thứ khác thì có.
Mức boost đồng-staking 2,35% này không phải là một “lãi suất”. Đó là một quỹ có kích thước cố định, được chia tỷ lệ cho mọi ví tham gia đồng-staking ngay tại thời điểm đó. Babylon nói điều này rất rõ trong tài liệu của họ: có nhiều đồng-staker hơn thì phần thưởng cá nhân sẽ nhỏ hơn. Khớp tỷ lệ hoàn hảo, phần chia thực của bạn vẫn phụ thuộc vào việc có bao nhiêu ví khác cũng khớp tỷ lệ đó—một con số thay đổi dù bạn không hề chạm vào vị trí của mình.
Không có dashboard nào theo dõi con số này theo thời gian thực. Bạn có thể xem “weight” (trọng số) của riêng mình. Bạn không thể thấy tổng trọng số của cả quỹ đang thay đổi bên dưới.
Khác với các rủi ro Babylon khác vốn có thể ẩn trong hạ tầng thiếu hoàn chỉnh hoặc do các nhà vận hành tập trung, rủi ro này lại hiện hữu ngay trước mắt — công thức hoàn toàn công khai. Thứ duy nhất thiếu là biết còn ai khác đang sử dụng nó.
Một điều đáng theo dõi: 2,35% này không phải nền tảng vững như đá tảng, mà là một con số do quản trị (governance) quyết định. Nó chỉ tồn tại vì một đề xuất hồi tháng 9 năm ngoái đã cắt “lạm phát” của Babylon thành các lát cố định: 1% cho người stake BTC, 2% cho người stake BABY, 2,35% cho co-stakers, phần còn lại chia ở nơi khác. Một cuộc bỏ phiếu trong tương lai có thể thay đổi kích thước lát đó theo cách tương tự như lần này đã tạo ra nó. Chưa có ai đề xuất thu hẹp nó, nên đây vẫn là một chỗ ngồi bạn phải theo dõi, chứ không phải là bàn bạn chắc chắn sẽ được giữ.
Có một “cạnh” (edge) thứ hai được gài sẵn trong công thức. Trọng số đủ điều kiện bị giới hạn ở mức nhỏ hơn trong hai giá trị: BABY của bạn chia cho 20.000, hoặc BTC của bạn. Vượt tỷ lệ và phần BABY dư chỉ nhận được đúng lãi suất staking thông thường. Chưa đạt tỷ lệ và chỉ một phần BTC của bạn được hưởng mức boost.
Việc ghép BTC và BABY được xây dựng để củng cố mối liên kết đó, và một quỹ dùng chung là cách hợp lý để tài trợ cho nó. Thiết kế không phải vấn đề. Vấn đề nằm ở chỗ bạn không thể nhìn thấy phần chia của mình sẽ dịch chuyển ra sao trước khi nó xảy ra.
Nếu bạn đã khớp tỷ lệ đúng như tôi đã làm, bạn không nhận được một mức 2,35% cố định. Bạn đang thuê một chỗ ngồi tại một cái bàn mà sẽ ngày càng đông người theo lịch của chính nó—bởi những người bạn sẽ không bao giờ thấy họ đến.
#baby $BABY @BabylonLabs_io
Nửa số BTC của tôi hiện đang được đặt cược thông qua Babylon. Tôi chưa bao giờ hỏi điều gì sẽ xảy ra nếu một nửa tập trình xác thực (validator) tắt đồng loạt — cho đến tối qua, khi tôi đọc phần “nửa còn lại” của bài nghiên cứu nền tảng về Babylon mà tôi đã bỏ qua.
Kiểm điểm (checkpointing) của Bitcoin đảm bảo an toàn. Chỉ cần một trình xác thực trung thực gửi bằng chứng tới Bitcoin là đủ để trừng phạt kẻ nói dối và quyết định lịch sử nào là thật. Tính sống động (liveness) là một vấn đề khác: liệu chuỗi có tiếp tục tạo khối hay không.
Đây là phần Bitcoin không thể chạm tới. Không có giao thức proof-of-stake nào đảm bảo tính sống động nếu các trình xác thực đối thủ vượt qua ngưỡng quá nửa tập hoạt động. Dù có Bitcoin đứng sau, dù có dịch vụ ghi thời gian (timestamping) đi kèm — cũng không, trừ khi toàn bộ dữ liệu của mọi trình xác thực được đăng lên on-chain, mà băng thông của Bitcoin chưa bao giờ được xây để mang việc đó.
Lập luận này đứng vững trước ác ý. Nó không nói gì về các trình xác thực chỉ đơn giản là ngừng xuất hiện. Chuỗi sẽ bị đình trệ y hệt trong cả hai trường hợp, và Bitcoin không thể cho bạn biết rốt cuộc trường hợp nào đã xảy ra.
“Được bảo đảm bởi Bitcoin” nghe như một lời cam kết duy nhất. Thực ra là hai. Bitcoin mua cho bạn sự chắc chắn về lịch sử nào là đúng. Nó không mua cho bạn một lời hứa rằng chuỗi vẫn tiếp tục chạy nếu một nửa trình xác thực biến mất cùng lúc — do mất điện (outage), rút lui (exit), hoặc một cuộc tấn công mà chẳng ai kịp phát hiện.
Một ủy ban cần một người ký trung thực, một relayer cần một người để luôn trực tuyến — những thứ đó được giải quyết khi có nhiều nhà vận hành tham gia hơn. Giới hạn này là bài toán đã được chứng minh bằng toán học, không phải vấn đề “nhân sự”. Càng giám sát chăm hơn cũng không làm thay đổi trần đó.
BTC của tôi bị khóa theo bất kỳ trường hợp nào. Bitcoin sẽ trao cho tôi biên nhận đúng khoảnh khắc chuỗi ngừng hoạt động. Việc làm cho chuỗi thở lại chưa bao giờ nằm trong phần chứng minh.
$BLESS $HOME
Nếu một nửa các validator của Babylon tắt đồng loạt tối nay, thì BTC của bạn sẽ ra sao?
Nửa số BTC của tôi hiện đang được đặt cược thông qua Babylon. Tôi chưa bao giờ hỏi điều gì sẽ xảy ra nếu một nửa tập trình xác thực (validator) tắt đồng loạt — cho đến tối qua, khi tôi đọc phần “nửa còn lại” của bài nghiên cứu nền tảng về Babylon mà tôi đã bỏ qua.
Kiểm điểm (checkpointing) của Bitcoin đảm bảo an toàn. Chỉ cần một trình xác thực trung thực gửi bằng chứng tới Bitcoin là đủ để trừng phạt kẻ nói dối và quyết định lịch sử nào là thật. Tính sống động (liveness) là một vấn đề khác: liệu chuỗi có tiếp tục tạo khối hay không.
Đây là phần Bitcoin không thể chạm tới. Không có giao thức proof-of-stake nào đảm bảo tính sống động nếu các trình xác thực đối thủ vượt qua ngưỡng quá nửa tập hoạt động. Dù có Bitcoin đứng sau, dù có dịch vụ ghi thời gian (timestamping) đi kèm — cũng không, trừ khi toàn bộ dữ liệu của mọi trình xác thực được đăng lên on-chain, mà băng thông của Bitcoin chưa bao giờ được xây để mang việc đó.
Lập luận này đứng vững trước ác ý. Nó không nói gì về các trình xác thực chỉ đơn giản là ngừng xuất hiện. Chuỗi sẽ bị đình trệ y hệt trong cả hai trường hợp, và Bitcoin không thể cho bạn biết rốt cuộc trường hợp nào đã xảy ra.
“Được bảo đảm bởi Bitcoin” nghe như một lời cam kết duy nhất. Thực ra là hai. Bitcoin mua cho bạn sự chắc chắn về lịch sử nào là đúng. Nó không mua cho bạn một lời hứa rằng chuỗi vẫn tiếp tục chạy nếu một nửa trình xác thực biến mất cùng lúc — do mất điện (outage), rút lui (exit), hoặc một cuộc tấn công mà chẳng ai kịp phát hiện.
Một ủy ban cần một người ký trung thực, một relayer cần một người để luôn trực tuyến — những thứ đó được giải quyết khi có nhiều nhà vận hành tham gia hơn. Giới hạn này là bài toán đã được chứng minh bằng toán học, không phải vấn đề “nhân sự”. Càng giám sát chăm hơn cũng không làm thay đổi trần đó.
BTC của tôi bị khóa theo bất kỳ trường hợp nào. Bitcoin sẽ trao cho tôi biên nhận đúng khoảnh khắc chuỗi ngừng hoạt động. Việc làm cho chuỗi thở lại chưa bao giờ nằm trong phần chứng minh.
$BLESS $HOME
Nếu một nửa các validator của Babylon tắt đồng loạt tối nay, thì BTC của bạn sẽ ra sao?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đã xác minh
@BabylonLabs_io $BABY #baby
Mỗi lần bạn unbond BTC khỏi Babylon, chín khóa sẽ đứng giữa Bitcoin của bạn và ví của bạn. Sáu trong số đó phải đồng ý trước khi bạn nhận lại được số tiền của mình.
Một trong chín khóa đó thuộc về Babylon Labs.
Bản chào hàng là "trustless" (không cần tin cậy): không có bên lưu ký, không có công ty nào nắm giữ BTC của bạn, chỉ có Bitcoin Script thực thi các quy tắc. Và điều đó là thật — không một khóa đơn lẻ nào có thể tự mình chạm vào tài sản của bạn. Nhưng unbonding là cánh cửa duy nhất để quay lại với những đồng coin của bạn trước khi thời hạn timelock 15 tháng hết hạn, và đội ngũ đã xây cánh cửa đó cũng nắm một trong những khóa để mở.
Đó không phải là một vụ bê bối. Tám khóa còn lại do các tổ chức được nêu tên, có uy tín nắm giữ, và ủy ban chỉ có thể chấp thuận hoặc từ chối các giao dịch tiêu chuẩn — hệ thống không được thiết kế để có thể bỏ chạy và chiếm đoạt BTC của bất kỳ ai. Tuy vậy, nếu bạn đọc kỹ các tài liệu riêng của Babylon, bạn sẽ thấy người xây dựng được liệt kê là một người ký trên hệ thống mà họ đã tạo ra, để hệ thống không cần người ký.
Hỏi một người đang stake Babylon tại sao họ đưa BTC vào giao thức, và "trustless" thường là từ đầu tiên bật ra khỏi miệng họ. Hỏi họ khóa số một đang do ai nắm giữ, và phần lớn sẽ không biết câu trả lời lại là Babylon Labs.
$IDOL
Việc người xây dựng nắm giữ một trong các khóa unbonding có làm bạn nhìn nhận "trustless" khác đi không?
Mỗi lần bạn unbond BTC khỏi Babylon, chín khóa sẽ đứng giữa Bitcoin của bạn và ví của bạn. Sáu trong số đó phải đồng ý trước khi bạn nhận lại được số tiền của mình.
Một trong chín khóa đó thuộc về Babylon Labs.
Bản chào hàng là "trustless" (không cần tin cậy): không có bên lưu ký, không có công ty nào nắm giữ BTC của bạn, chỉ có Bitcoin Script thực thi các quy tắc. Và điều đó là thật — không một khóa đơn lẻ nào có thể tự mình chạm vào tài sản của bạn. Nhưng unbonding là cánh cửa duy nhất để quay lại với những đồng coin của bạn trước khi thời hạn timelock 15 tháng hết hạn, và đội ngũ đã xây cánh cửa đó cũng nắm một trong những khóa để mở.
Đó không phải là một vụ bê bối. Tám khóa còn lại do các tổ chức được nêu tên, có uy tín nắm giữ, và ủy ban chỉ có thể chấp thuận hoặc từ chối các giao dịch tiêu chuẩn — hệ thống không được thiết kế để có thể bỏ chạy và chiếm đoạt BTC của bất kỳ ai. Tuy vậy, nếu bạn đọc kỹ các tài liệu riêng của Babylon, bạn sẽ thấy người xây dựng được liệt kê là một người ký trên hệ thống mà họ đã tạo ra, để hệ thống không cần người ký.
Hỏi một người đang stake Babylon tại sao họ đưa BTC vào giao thức, và "trustless" thường là từ đầu tiên bật ra khỏi miệng họ. Hỏi họ khóa số một đang do ai nắm giữ, và phần lớn sẽ không biết câu trả lời lại là Babylon Labs.
$IDOL
Việc người xây dựng nắm giữ một trong các khóa unbonding có làm bạn nhìn nhận "trustless" khác đi không?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
2 giờ sáng vẫn còn thức, đọc tài liệu checkpointing của Babylon hoàn toàn không có lý do gì khác ngoài việc tôi không thể ngủ. Một dòng đã dừng việc cuộn của tôi: chỉ cần một vigilante trung thực và đang hoạt động xuyên suốt mạng là đủ để đảm bảo các checkpoint tới Bitcoin diễn ra thành công và an toàn.
Đọc nhanh thôi, nghe như phi tập trung đang làm đúng nhiệm vụ. Hàng chục nhà vận hành độc lập, chỉ cần một người cư xử đúng.
Tôi quay lại bài báo học thuật năm 2022 của chính Babylon, đồng tác giả bởi những người sáng lập của họ—bài chứng minh tuyên bố này như một định lý theo nghĩa hình thức, thay vì một câu marketing. Chứng minh đúng với một điều kiện: luôn luôn có một validator trung thực đang hoạt động. Bài báo nêu thẳng điều đó.
Nhưng đây là phần nó không nói rõ. “Một là đủ về mặt toán học” và “một người hiện đang online” là hai loại bảo đảm khác nhau. Chỉ mệnh đề đầu tiên đi kèm một bản chứng minh.
Rồi cùng một câu lại xuất hiện lần nữa, lần này cạnh covenant emulator và IBC relayer, được gọi tên như những chương trình riêng của chúng: vận hành an toàn cần ít nhất một nhà vận hành trung thực cho mỗi chương trình được liệt kê, nếu không hệ thống sẽ báo động. Không chắc điều đó có bao phủ cả ba đồng đều hay nó chỉ được viết với ý định dành cho bộ vigilante. Dù sao thì con số nhân sự vẫn không được công bố.
Babylon gọi đây là tự nguyện, ai cũng có thể chạy một. Đúng—và nó vẫn không nói hiện tại có bao nhiêu người đang chạy, hoặc liệu con số đó có được duy trì trong lúc phí giao dịch Bitcoin tăng vọt mà chẳng ai muốn phải trả.
Có một lý do khiến không ai công bố con số đó. Tiết lộ lớp đệm mỏng bao nhiêu sẽ giúp kẻ tấn công nhiều hơn là giúp bạn.
Nếu bạn đang stake thông qua Babylon ngay lúc này, thì giả định đang nằm ngay bên dưới BTC của bạn mà không dashboard nào hiển thị: không phải là liệu bài toán toán học có đúng hay không, mà là liệu có ai đó thực sự đang thức để vận hành nó—hôm nay và mỗi đêm sau đó.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Bạn có stake không nếu số lượng “một nhà vận hành trung thực” là không xác định? 👀
Đọc nhanh thôi, nghe như phi tập trung đang làm đúng nhiệm vụ. Hàng chục nhà vận hành độc lập, chỉ cần một người cư xử đúng.
Tôi quay lại bài báo học thuật năm 2022 của chính Babylon, đồng tác giả bởi những người sáng lập của họ—bài chứng minh tuyên bố này như một định lý theo nghĩa hình thức, thay vì một câu marketing. Chứng minh đúng với một điều kiện: luôn luôn có một validator trung thực đang hoạt động. Bài báo nêu thẳng điều đó.
Nhưng đây là phần nó không nói rõ. “Một là đủ về mặt toán học” và “một người hiện đang online” là hai loại bảo đảm khác nhau. Chỉ mệnh đề đầu tiên đi kèm một bản chứng minh.
Rồi cùng một câu lại xuất hiện lần nữa, lần này cạnh covenant emulator và IBC relayer, được gọi tên như những chương trình riêng của chúng: vận hành an toàn cần ít nhất một nhà vận hành trung thực cho mỗi chương trình được liệt kê, nếu không hệ thống sẽ báo động. Không chắc điều đó có bao phủ cả ba đồng đều hay nó chỉ được viết với ý định dành cho bộ vigilante. Dù sao thì con số nhân sự vẫn không được công bố.
Babylon gọi đây là tự nguyện, ai cũng có thể chạy một. Đúng—và nó vẫn không nói hiện tại có bao nhiêu người đang chạy, hoặc liệu con số đó có được duy trì trong lúc phí giao dịch Bitcoin tăng vọt mà chẳng ai muốn phải trả.
Có một lý do khiến không ai công bố con số đó. Tiết lộ lớp đệm mỏng bao nhiêu sẽ giúp kẻ tấn công nhiều hơn là giúp bạn.
Nếu bạn đang stake thông qua Babylon ngay lúc này, thì giả định đang nằm ngay bên dưới BTC của bạn mà không dashboard nào hiển thị: không phải là liệu bài toán toán học có đúng hay không, mà là liệu có ai đó thực sự đang thức để vận hành nó—hôm nay và mỗi đêm sau đó.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Bạn có stake không nếu số lượng “một nhà vận hành trung thực” là không xác định? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đã xác minh
#baby $BABY @BabylonLabs_io
Trước đây tôi từng nghĩ rằng việc cắt (slashing) là cách Babylon trừng phạt sự dối trá. Nhưng điều đó đã thay đổi vào lúc 2 giờ sáng khi tôi lướt qua một bản kiểm toán bảo mật độc lập về việc triển khai EOTS—loại tài liệu mà chẳng ai mở nếu không có lý do.
Cơ chế này thật sự tinh tế theo đúng nghĩa của nó. Một nhà cung cấp tính chung cuộc (finality provider) cam kết một mẩu ngẫu nhiên trước khi ký bất kỳ khối nào ở một độ cao nhất định. Ký một lần, không có gì xảy ra. Ký hai lần—với hai thông điệp khác nhau—và phần toán học đằng sau chữ ký Schnorr sẽ biến cùng một dữ liệu ngẫu nhiên đó thành khóa riêng bị lộ của nhà cung cấp. Việc cố ý ký đôi (double-signing) trở thành tự trừng phạt theo chính cấu trúc, và có một lý do cho điều đó: giao thức chỉ có thể đọc chữ ký, không thể đọc ý định, nên một quy tắc đủ nghiêm để bắt kẻ tấn công sẽ không thể phân biệt kẻ tấn công với một tai nạn.
Chính sự đánh đổi đó là điều bản kiểm toán đã nêu. Một cuộc tấn công có chủ đích và một lần chuyển đổi dự phòng (failover) của node dự phòng trung thực kích hoạt tại cùng độ cao sẽ tạo ra đúng cùng một mẫu chữ ký. Cả hai đều trông y hệt EOTS. Cả hai đều bị slashed theo cách như nhau, bị đóng dấu (tombstoned), và không có việc khôi phục lại.
Điều này không chỉ là giả thuyết. Hex Trust—một bên lưu ký tổ chức vận hành hạ tầng cung cấp tính chung cuộc trên Babylon—liệt kê các biện pháp bảo vệ cụ thể chống lại đúng trường hợp này: không tái sử dụng khóa riêng giữa các máy, failover thủ công thay vì tự động, vì failover tự động chính là thứ có thể tạo ra hai người ký trực tuyến cho cùng một khóa cùng lúc.
Đây là phần không có câu trả lời rõ ràng. Không có chuẩn công khai nào cho biết một provider cấu hình failover theo kiểu gì. Bạn có thể xem hoa hồng (commission), thời gian hoạt động (uptime), số lượng người ủy thác (delegator count). Còn những thứ này—không. Và cũng không, trước khi BTC của bạn đã bị khóa.
Việc ủy thác chưa bao giờ chỉ là một canh bạc rằng người vận hành sẽ không tấn công bạn. Đó còn là một canh bạc rằng hạ tầng của họ sẽ không có ngày tồi tệ trong suốt thời gian BTC của bạn còn bị khóa—trên một chi tiết mà giao thức không thể biết trước được.
$KOMA
Trước đây tôi từng nghĩ rằng việc cắt (slashing) là cách Babylon trừng phạt sự dối trá. Nhưng điều đó đã thay đổi vào lúc 2 giờ sáng khi tôi lướt qua một bản kiểm toán bảo mật độc lập về việc triển khai EOTS—loại tài liệu mà chẳng ai mở nếu không có lý do.
Cơ chế này thật sự tinh tế theo đúng nghĩa của nó. Một nhà cung cấp tính chung cuộc (finality provider) cam kết một mẩu ngẫu nhiên trước khi ký bất kỳ khối nào ở một độ cao nhất định. Ký một lần, không có gì xảy ra. Ký hai lần—với hai thông điệp khác nhau—và phần toán học đằng sau chữ ký Schnorr sẽ biến cùng một dữ liệu ngẫu nhiên đó thành khóa riêng bị lộ của nhà cung cấp. Việc cố ý ký đôi (double-signing) trở thành tự trừng phạt theo chính cấu trúc, và có một lý do cho điều đó: giao thức chỉ có thể đọc chữ ký, không thể đọc ý định, nên một quy tắc đủ nghiêm để bắt kẻ tấn công sẽ không thể phân biệt kẻ tấn công với một tai nạn.
Chính sự đánh đổi đó là điều bản kiểm toán đã nêu. Một cuộc tấn công có chủ đích và một lần chuyển đổi dự phòng (failover) của node dự phòng trung thực kích hoạt tại cùng độ cao sẽ tạo ra đúng cùng một mẫu chữ ký. Cả hai đều trông y hệt EOTS. Cả hai đều bị slashed theo cách như nhau, bị đóng dấu (tombstoned), và không có việc khôi phục lại.
Điều này không chỉ là giả thuyết. Hex Trust—một bên lưu ký tổ chức vận hành hạ tầng cung cấp tính chung cuộc trên Babylon—liệt kê các biện pháp bảo vệ cụ thể chống lại đúng trường hợp này: không tái sử dụng khóa riêng giữa các máy, failover thủ công thay vì tự động, vì failover tự động chính là thứ có thể tạo ra hai người ký trực tuyến cho cùng một khóa cùng lúc.
Đây là phần không có câu trả lời rõ ràng. Không có chuẩn công khai nào cho biết một provider cấu hình failover theo kiểu gì. Bạn có thể xem hoa hồng (commission), thời gian hoạt động (uptime), số lượng người ủy thác (delegator count). Còn những thứ này—không. Và cũng không, trước khi BTC của bạn đã bị khóa.
Việc ủy thác chưa bao giờ chỉ là một canh bạc rằng người vận hành sẽ không tấn công bạn. Đó còn là một canh bạc rằng hạ tầng của họ sẽ không có ngày tồi tệ trong suốt thời gian BTC của bạn còn bị khóa—trên một chi tiết mà giao thức không thể biết trước được.
$KOMA
Đã xác minh
$BABY $UAI $COTI #baby @BabylonLabs_io
Ban đầu tôi cho rằng ủy ban giao ước chỉ là một bước “tạm thời”, thứ Babylon sẽ rút lui khi bản lộ trình của chính họ đã chín muồi—giống như hầu hết các giao thức non trẻ đều hứa sẽ phi tập trung hóa theo lịch trình riêng. Nhưng tài liệu lại nói điều gì đó trầm lặng và kỳ lạ hơn.
Ủy ban tồn tại vì chính Bitcoin không có cách sẵn có để thực thi giao ước: không có opcode nào có thể bắt một UTXO chỉ được chi theo các quy tắc đã thỏa thuận trước. Vì vậy Babylon đã xây dựng một multisig 6-trên-9 để mô phỏng chức năng còn thiếu đó: theo dõi các yêu cầu staking, đồng ký khi unbonding và slashing, đứng ra thay cho một năng lực mà Bitcoin Script hiện tại đơn giản là chưa có. Phần này là kỹ thuật trung thực để lấp một khoảng trống thật, và giả định tin cậy cũng “nhẹ” hơn đáng kể so với một multisig kiểu lưu ký thông thường—giống kiểu “sự trung thực tồn tại” hơn là “trung thực đa số”: chỉ cần một người ký trung thực là đủ để ngăn chặn việc đánh cắp.
Điều làm tôi dừng lại chính là điều kiện kết thúc. Tài liệu của chính Babylon không nói rằng ủy ban sẽ giải thể khi quản trị trưởng thành, hoặc khi đạt một ngưỡng TVL nhất định, hoặc khi một mốc nội bộ nào đó được triển khai xong. Nó nói rằng ủy ban sẽ tiếp tục tồn tại cho đến khi chức năng giao ước trở nên sẵn có trực tiếp trên Bitcoin—thông qua các opcode như OP-CAT hoặc OP-CTV—những thứ Bitcoin Core chưa áp dụng và cũng không có cam kết lộ trình thời gian cụ thể để áp dụng. Ngày nghỉ hưu không nằm trong lộ trình của Babylon. Nó nằm trong quy trình quản trị của một giao thức khác: Babylon không có quyền bỏ phiếu và cũng không có khả năng đẩy nhanh tiến độ.
Vì vậy, niềm tin không biến mất khi Babylon gọi đây là một hệ thống được bảo đảm bởi Bitcoin. Nó chỉ dịch xa thêm một lớp nữa: rời khỏi một multisig có danh sách thành viên xác định, sang một bản soft fork của Bitcoin—thứ có thể hoặc không có mặt trong thập kỷ này. “Sáu trên chín” người ký mà ta biết ít nhất cũng là một giả định tin cậy mà bạn có thể gọi tên. Một bản nâng cấp opcode đang chờ, không deadline, thì chỉ là một giả định tin cậy mà bạn phải… chờ.
Ủy ban giao ước sẽ vẫn tồn tại cho đến khi Bitcoin thêm các opcode giao ước. Không có timeline của Babylon chi phối nó.
Ý kiến của bạn? 👀
Ban đầu tôi cho rằng ủy ban giao ước chỉ là một bước “tạm thời”, thứ Babylon sẽ rút lui khi bản lộ trình của chính họ đã chín muồi—giống như hầu hết các giao thức non trẻ đều hứa sẽ phi tập trung hóa theo lịch trình riêng. Nhưng tài liệu lại nói điều gì đó trầm lặng và kỳ lạ hơn.
Ủy ban tồn tại vì chính Bitcoin không có cách sẵn có để thực thi giao ước: không có opcode nào có thể bắt một UTXO chỉ được chi theo các quy tắc đã thỏa thuận trước. Vì vậy Babylon đã xây dựng một multisig 6-trên-9 để mô phỏng chức năng còn thiếu đó: theo dõi các yêu cầu staking, đồng ký khi unbonding và slashing, đứng ra thay cho một năng lực mà Bitcoin Script hiện tại đơn giản là chưa có. Phần này là kỹ thuật trung thực để lấp một khoảng trống thật, và giả định tin cậy cũng “nhẹ” hơn đáng kể so với một multisig kiểu lưu ký thông thường—giống kiểu “sự trung thực tồn tại” hơn là “trung thực đa số”: chỉ cần một người ký trung thực là đủ để ngăn chặn việc đánh cắp.
Điều làm tôi dừng lại chính là điều kiện kết thúc. Tài liệu của chính Babylon không nói rằng ủy ban sẽ giải thể khi quản trị trưởng thành, hoặc khi đạt một ngưỡng TVL nhất định, hoặc khi một mốc nội bộ nào đó được triển khai xong. Nó nói rằng ủy ban sẽ tiếp tục tồn tại cho đến khi chức năng giao ước trở nên sẵn có trực tiếp trên Bitcoin—thông qua các opcode như OP-CAT hoặc OP-CTV—những thứ Bitcoin Core chưa áp dụng và cũng không có cam kết lộ trình thời gian cụ thể để áp dụng. Ngày nghỉ hưu không nằm trong lộ trình của Babylon. Nó nằm trong quy trình quản trị của một giao thức khác: Babylon không có quyền bỏ phiếu và cũng không có khả năng đẩy nhanh tiến độ.
Vì vậy, niềm tin không biến mất khi Babylon gọi đây là một hệ thống được bảo đảm bởi Bitcoin. Nó chỉ dịch xa thêm một lớp nữa: rời khỏi một multisig có danh sách thành viên xác định, sang một bản soft fork của Bitcoin—thứ có thể hoặc không có mặt trong thập kỷ này. “Sáu trên chín” người ký mà ta biết ít nhất cũng là một giả định tin cậy mà bạn có thể gọi tên. Một bản nâng cấp opcode đang chờ, không deadline, thì chỉ là một giả định tin cậy mà bạn phải… chờ.
Ủy ban giao ước sẽ vẫn tồn tại cho đến khi Bitcoin thêm các opcode giao ước. Không có timeline của Babylon chi phối nó.
Ý kiến của bạn? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Tuần trước, khi chọn một nhà cung cấp tính cuối cùng (finality provider), tôi nhìn vào danh sách khoảng 30 tên đã được xác minh và suýt bấm vào cái nào đã có nhiều người ủy quyền nhất. Đó là phản xạ giống hệt đã biến một phần lớn việc staking của Ethereum thành câu chuyện về Lido.
Rồi tôi thực sự đọc hướng dẫn staking của Babylon.
Trong đó họ nêu thẳng rủi ro: ủy thác cho các nhà cung cấp phổ biến nhất sẽ làm tăng rủi ro tập trung hóa. Đây không phải nhận xét của một người chỉ trích; tài liệu chính thức của họ nói như vậy.
➡ Khoảng 30 nhà cung cấp có dấu kiểm xác minh trong ứng dụng.
➡ Danh sách đó không giới hạn mức ủy thác mà bất kỳ một nhà cung cấp đơn lẻ nào có thể hấp thụ.
Hãy ghi công cho Babylon vì họ nói thẳng điều này; hầu hết các sản phẩm staking không bao giờ cảnh báo người dùng cuối trước khi họ bấm vào.
Đây là điều đọng lại trong tôi. Dấu kiểm tồn tại để tạo niềm tin. Nhưng nếu đa số người staker mặc định chọn tên đã được xác minh nào có nhiều người ủy quyền nhất, đúng như mô hình Ethereum đã trải qua, thứ được tạo ra để xây dựng niềm tin lại trở thành cơ chế tập trung hóa chính rủi ro mà họ cảnh báo.
Tôi tìm các con số thực tế về tỷ lệ ủy thác—ví dụ top 5 hoặc top 10 nhà cung cấp tính cuối cùng kiểm soát kết hợp bao nhiêu. Không thấy gì công khai. Một bài viết/ghi chú của chính một sàn giao dịch crypto về giao thức gọi điều đó là "vẫn cần tiếp tục thảo luận"; đây là một vấn đề mở được một nguồn bên ngoài nêu ra, không phải điều mà Babylon tự mình đã đề cập trên hồ sơ.
Tôi chia phần ủy thác của mình cho ba nhà cung cấp nhỏ hơn thay vì chỉ chọn một nhà lớn. Ở quy mô này, có lẽ nó gần giống một cử chỉ mang tính biểu tượng hơn là một giải pháp thực sự, và tôi biết điều đó.
@BabylonLabs_io $BABY #baby $ON
"Bạn có định ủy thác cho một nhà cung cấp tính cuối cùng nhỏ hơn một cách chủ đích không?"
Rồi tôi thực sự đọc hướng dẫn staking của Babylon.
Trong đó họ nêu thẳng rủi ro: ủy thác cho các nhà cung cấp phổ biến nhất sẽ làm tăng rủi ro tập trung hóa. Đây không phải nhận xét của một người chỉ trích; tài liệu chính thức của họ nói như vậy.
➡ Khoảng 30 nhà cung cấp có dấu kiểm xác minh trong ứng dụng.
➡ Danh sách đó không giới hạn mức ủy thác mà bất kỳ một nhà cung cấp đơn lẻ nào có thể hấp thụ.
Hãy ghi công cho Babylon vì họ nói thẳng điều này; hầu hết các sản phẩm staking không bao giờ cảnh báo người dùng cuối trước khi họ bấm vào.
Đây là điều đọng lại trong tôi. Dấu kiểm tồn tại để tạo niềm tin. Nhưng nếu đa số người staker mặc định chọn tên đã được xác minh nào có nhiều người ủy quyền nhất, đúng như mô hình Ethereum đã trải qua, thứ được tạo ra để xây dựng niềm tin lại trở thành cơ chế tập trung hóa chính rủi ro mà họ cảnh báo.
Tôi tìm các con số thực tế về tỷ lệ ủy thác—ví dụ top 5 hoặc top 10 nhà cung cấp tính cuối cùng kiểm soát kết hợp bao nhiêu. Không thấy gì công khai. Một bài viết/ghi chú của chính một sàn giao dịch crypto về giao thức gọi điều đó là "vẫn cần tiếp tục thảo luận"; đây là một vấn đề mở được một nguồn bên ngoài nêu ra, không phải điều mà Babylon tự mình đã đề cập trên hồ sơ.
Tôi chia phần ủy thác của mình cho ba nhà cung cấp nhỏ hơn thay vì chỉ chọn một nhà lớn. Ở quy mô này, có lẽ nó gần giống một cử chỉ mang tính biểu tượng hơn là một giải pháp thực sự, và tôi biết điều đó.
@BabylonLabs_io $BABY #baby $ON
"Bạn có định ủy thác cho một nhà cung cấp tính cuối cùng nhỏ hơn một cách chủ đích không?"
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
#baby @BabylonLabs_io
Gần đây tôi suýt bỏ một lượng BTC nhỏ vào vị thế cho vay được hậu thuẫn bởi một “vault”. Trước khi làm điều đó, tôi muốn biết một điều: nếu thị trường biến động nhanh bất lợi cho tôi, thì rốt cuộc cái gì quyết định khi nào tôi bị thanh lý? Câu hỏi đó đã kéo tôi rời khỏi lớp vỏ marketing để đi thẳng vào trang web của Babylon — nơi mà từ “trustless” (không cần tin cậy) ngừng còn áp dụng. Nó không bị chôn giấu. Chỉ là nó không thể tồn tại khi được “dịch” thành mọi tiêu đề được xây dựng xoay quanh đúng một từ đó. ➡ Trang Learn của chính Babylon nói thẳng rằng rủi ro thực nằm ở phía DeFi, chứ không phải ở bản thân vault, và đưa thanh lý trong cho vay làm ví dụ. ➡ Bản whitepaper cũng khẳng định điều đó: thanh lý cần một chữ ký từ price oracle (nguồn dữ liệu giá), được xem như một phụ thuộc tách biệt so với thiết kế lõi của vault. Ghi nhận Babylon — họ tự viết ra điều này. Không ai phải “đào” nó ra từ họ. Đây là phần khiến tôi bị ám ảnh, phần thực sự đã thay đổi mức tiền tôi sắp sửa nạp vào. “A price oracle” nghe thật trừu tượng, cho đến khi có một báo cáo về đúng hệ thống này đã nêu rõ mạng nào thực sự thiết lập mối quan hệ đó với Babylon: Band Protocol và Pyth — cùng là các mạng có mục đích chung, định giá hàng chục chuỗi khác cùng lúc. Tài liệu của Babylon không nêu trực tiếp, nên hãy xem cặp ghép cụ thể này là được báo cáo, chứ không phải do chính Babylon xác nhận. Nếu một trong các nguồn cấp dữ liệu đó bị trễ hoặc sai trong lúc biến động nhanh, thì thanh lý của tôi vẫn kích hoạt đúng như phần mềm đã mã hoá. Hoạt động đúng theo thông tin sai. Lớp nền tảng Bitcoin không hề “bỏ phiếu” cho kết cục đó. Vault làm đúng như lời họ hứa. Oracle chỉ cung cấp cho nó một thứ không đúng. Đó không phải vault thất bại. Đó là rủi ro DeFi — khoác nhãn trustless — và kế thừa mọi lịch sử sự cố mà chính nguồn dữ liệu giá của nó từng mang theo từ các chuỗi khác mà tôi thậm chí không dùng. Tôi vẫn nạp tiền. Chỉ là ít hơn so với một giờ trước. “Trustless” mô tả điều gì xảy ra với BTC của bạn. Nó chưa bao giờ là một lời hứa về điều gì sẽ xảy ra với tiền của bạn sau khi tiền rời khỏi vault.
$BROCCOLIF3B $ON $BABY
Gần đây tôi suýt bỏ một lượng BTC nhỏ vào vị thế cho vay được hậu thuẫn bởi một “vault”. Trước khi làm điều đó, tôi muốn biết một điều: nếu thị trường biến động nhanh bất lợi cho tôi, thì rốt cuộc cái gì quyết định khi nào tôi bị thanh lý? Câu hỏi đó đã kéo tôi rời khỏi lớp vỏ marketing để đi thẳng vào trang web của Babylon — nơi mà từ “trustless” (không cần tin cậy) ngừng còn áp dụng. Nó không bị chôn giấu. Chỉ là nó không thể tồn tại khi được “dịch” thành mọi tiêu đề được xây dựng xoay quanh đúng một từ đó. ➡ Trang Learn của chính Babylon nói thẳng rằng rủi ro thực nằm ở phía DeFi, chứ không phải ở bản thân vault, và đưa thanh lý trong cho vay làm ví dụ. ➡ Bản whitepaper cũng khẳng định điều đó: thanh lý cần một chữ ký từ price oracle (nguồn dữ liệu giá), được xem như một phụ thuộc tách biệt so với thiết kế lõi của vault. Ghi nhận Babylon — họ tự viết ra điều này. Không ai phải “đào” nó ra từ họ. Đây là phần khiến tôi bị ám ảnh, phần thực sự đã thay đổi mức tiền tôi sắp sửa nạp vào. “A price oracle” nghe thật trừu tượng, cho đến khi có một báo cáo về đúng hệ thống này đã nêu rõ mạng nào thực sự thiết lập mối quan hệ đó với Babylon: Band Protocol và Pyth — cùng là các mạng có mục đích chung, định giá hàng chục chuỗi khác cùng lúc. Tài liệu của Babylon không nêu trực tiếp, nên hãy xem cặp ghép cụ thể này là được báo cáo, chứ không phải do chính Babylon xác nhận. Nếu một trong các nguồn cấp dữ liệu đó bị trễ hoặc sai trong lúc biến động nhanh, thì thanh lý của tôi vẫn kích hoạt đúng như phần mềm đã mã hoá. Hoạt động đúng theo thông tin sai. Lớp nền tảng Bitcoin không hề “bỏ phiếu” cho kết cục đó. Vault làm đúng như lời họ hứa. Oracle chỉ cung cấp cho nó một thứ không đúng. Đó không phải vault thất bại. Đó là rủi ro DeFi — khoác nhãn trustless — và kế thừa mọi lịch sử sự cố mà chính nguồn dữ liệu giá của nó từng mang theo từ các chuỗi khác mà tôi thậm chí không dùng. Tôi vẫn nạp tiền. Chỉ là ít hơn so với một giờ trước. “Trustless” mô tả điều gì xảy ra với BTC của bạn. Nó chưa bao giờ là một lời hứa về điều gì sẽ xảy ra với tiền của bạn sau khi tiền rời khỏi vault.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đúng một phần
#baby $BABY @BabylonLabs_io
Gần đây, tuần trước tôi suýt đưa một lượng nhỏ BTC vào một vị thế cho vay được bảo đảm bởi vault. Trước khi làm, tôi muốn biết một điều: nếu thị trường biến động nhanh theo hướng bất lợi cho tôi, thì điều gì thực sự quyết định lúc nào tôi bị thanh lý?
Chính câu hỏi đó đã khiến tôi tìm hiểu sâu hơn, vượt qua lớp marketing, để xem ở trang web chính thức của Babylon—tại nơi mà từ "trustless" (không cần tin cậy) không còn áp dụng.
Nó không bị chôn giấu. Chỉ là nó không chịu được việc bị dịch/diễn giải lại trong mọi tiêu đề được xây dựng chỉ xoay quanh một từ đó.
➡ Trang Learn của chính Babylon viết thẳng rằng rủi ro thực nằm ở phía DeFi, chứ không nằm ngay trong bản thân vault, và đưa thanh lý trong cho vay làm ví dụ.
➡ Whitepaper cũng khẳng định điều này: việc thanh lý cần một chữ ký từ một price oracle (nguồn định giá), được xem như một sự phụ thuộc riêng tách khỏi thiết kế cốt lõi của vault.
Hãy ghi nhận Babylon — họ tự viết ra những điều này. Không ai phải moi chúng từ họ.
Đây là đoạn khiến tôi thực sự để lại ấn tượng—đoạn đã làm thay đổi mức tiền tôi sắp sửa gửi. "Một price oracle" nghe có vẻ trừu tượng, cho đến khi có một báo cáo về đúng hệ thống này nêu rõ mạng nào thực sự thiết lập mối quan hệ đó với Babylon: Band Protocol và Pyth, cũng chính là các mạng định giá dùng cho mục đích chung, đồng thời định giá cho hàng chục chuỗi khác cùng lúc. Tài liệu của Babylon không nêu trực tiếp tên các mạng này, nên hãy xem cặp đôi cụ thể đó là theo báo cáo, không phải do chính Babylon xác nhận.
Nếu một trong các nguồn cấp dữ liệu đó đến trễ hoặc sai trong một biến động nhanh, lệnh thanh lý của tôi vẫn sẽ kích hoạt đúng như code đã định. Đúng—phản ứng dựa trên thông tin xấu. Lớp nền Bitcoin không có lá phiếu quyết định cho kết cục đó. Vault chỉ làm đúng những gì nó đã cam kết. Oracle chỉ đưa cho nó một thứ sai.
Đó không phải là vault thất bại. Đó là rủi ro của DeFi, mang nhãn trustless, và kế thừa mọi lịch sử sự cố mà price feed thực tế của nó đã mang sẵn từ những chuỗi khác mà tôi thậm chí không dùng.
Tôi vẫn gửi tiền. Chỉ là ít hơn so với một giờ trước.
Trustless mô tả điều gì xảy ra với BTC của bạn. Nó chưa bao giờ là lời hứa về chuyện gì xảy ra với tiền của bạn sau khi nó rời khỏi vault.
$EUL
Một vault “trustless” vẫn có thể phụ thuộc vào oracle chứ?
Gần đây, tuần trước tôi suýt đưa một lượng nhỏ BTC vào một vị thế cho vay được bảo đảm bởi vault. Trước khi làm, tôi muốn biết một điều: nếu thị trường biến động nhanh theo hướng bất lợi cho tôi, thì điều gì thực sự quyết định lúc nào tôi bị thanh lý?
Chính câu hỏi đó đã khiến tôi tìm hiểu sâu hơn, vượt qua lớp marketing, để xem ở trang web chính thức của Babylon—tại nơi mà từ "trustless" (không cần tin cậy) không còn áp dụng.
Nó không bị chôn giấu. Chỉ là nó không chịu được việc bị dịch/diễn giải lại trong mọi tiêu đề được xây dựng chỉ xoay quanh một từ đó.
➡ Trang Learn của chính Babylon viết thẳng rằng rủi ro thực nằm ở phía DeFi, chứ không nằm ngay trong bản thân vault, và đưa thanh lý trong cho vay làm ví dụ.
➡ Whitepaper cũng khẳng định điều này: việc thanh lý cần một chữ ký từ một price oracle (nguồn định giá), được xem như một sự phụ thuộc riêng tách khỏi thiết kế cốt lõi của vault.
Hãy ghi nhận Babylon — họ tự viết ra những điều này. Không ai phải moi chúng từ họ.
Đây là đoạn khiến tôi thực sự để lại ấn tượng—đoạn đã làm thay đổi mức tiền tôi sắp sửa gửi. "Một price oracle" nghe có vẻ trừu tượng, cho đến khi có một báo cáo về đúng hệ thống này nêu rõ mạng nào thực sự thiết lập mối quan hệ đó với Babylon: Band Protocol và Pyth, cũng chính là các mạng định giá dùng cho mục đích chung, đồng thời định giá cho hàng chục chuỗi khác cùng lúc. Tài liệu của Babylon không nêu trực tiếp tên các mạng này, nên hãy xem cặp đôi cụ thể đó là theo báo cáo, không phải do chính Babylon xác nhận.
Nếu một trong các nguồn cấp dữ liệu đó đến trễ hoặc sai trong một biến động nhanh, lệnh thanh lý của tôi vẫn sẽ kích hoạt đúng như code đã định. Đúng—phản ứng dựa trên thông tin xấu. Lớp nền Bitcoin không có lá phiếu quyết định cho kết cục đó. Vault chỉ làm đúng những gì nó đã cam kết. Oracle chỉ đưa cho nó một thứ sai.
Đó không phải là vault thất bại. Đó là rủi ro của DeFi, mang nhãn trustless, và kế thừa mọi lịch sử sự cố mà price feed thực tế của nó đã mang sẵn từ những chuỗi khác mà tôi thậm chí không dùng.
Tôi vẫn gửi tiền. Chỉ là ít hơn so với một giờ trước.
Trustless mô tả điều gì xảy ra với BTC của bạn. Nó chưa bao giờ là lời hứa về chuyện gì xảy ra với tiền của bạn sau khi nó rời khỏi vault.
$EUL
Một vault “trustless” vẫn có thể phụ thuộc vào oracle chứ?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
$EUL $CHILLGUY Goooo
và cho tôi phản hồi
và cho tôi phản hồi
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
#baby $BABY @BabylonLabs_io
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
Đêm qua tôi không ngủ được, nên tôi kéo lên ba bản thuyết minh riêng rẽ về phía Babylon Aave Temp Check và đặt chúng cạnh nhau, nhiều hơn vì thói quen hơn là vì bất cứ điều gì khác.
Một từ cứ cắn mãi trong đầu tôi.
Bitcoin.com, Cointribune và LiveBitcoinNews đều mô tả luồng thanh lý TBV theo cùng một cách. Một liquidator không cần cấp phép sẽ hoán đổi một vault bị tịch thu lấy WBTC ngay lập tức, với một mức premium nhỏ. Một nhóm “nhà arbitrage có cấp phép” riêng sau đó sẽ mua vị thế đó và đổi lấy BTC thật sau đó, theo đúng timeline của Bitcoin.
Cho Babylon điểm tốt cho nửa đầu: kiểm tra thanh lý không cần cấp phép đúng như những gì họ quảng cáo.
Nhưng chính là nửa thứ hai khiến tôi phải đào sâu hơn cả phần đề xuất của Aave. Bản whitepaper tháng 8 của Babylon về Trustless Bitcoin Vaults của họ không hề nói “có cấp phép” — nó nói rằng các lệnh thanh lý chạy qua “các liquidator được cho phép” (whitelisted) theo dõi giá và trạng thái vault. Khác từ, nhưng cùng một dáng vẻ. Một nhà phân tích độc lập đã trao đổi tin nhắn với nhóm Babylon trên X nêu thẳng ý đó với họ: đủ nhiều bên trong danh sách trắng hoạt động đúng cách là một giả định về niềm tin mà phần marketing không nhắc tới.
Vậy nên, từ đó hóa ra là chính xác. Câu hỏi thực sự là vì sao vai trò đó lại phải bị hạn chế ngay từ đầu, trong khi phía hoán đổi WBTC thì không. Ngôn ngữ scripting của Bitcoin không thể đánh giá trạng thái off-chain tùy ý. BitVM3 giải quyết điều đó bằng cách bọc một bộ kiểm tra bằng chứng zero-knowledge bên trong một mạch được mã hóa (garbled circuit), nhưng vẫn có ai đó phải tạo và nộp bằng chứng đó để kích hoạt việc đổi trả. Phía hoán đổi WBTC thì dễ để giữ không cần cấp phép — bất kỳ liquidator nào có vốn cũng có thể thực hiện giao dịch. Việc nộp bằng chứng mới là bài toán khó mà BitVM3 vẫn chưa giải quyết.
Điều này không phải về việc vault có trustless hay không. Babylon không giấu việc whitelisting trong whitepaper của riêng họ. Trustlessness không biến mất ở đây. Nó chỉ kết thúc sớm hơn một bước so với những gì phần lớn phần đưa tin nói.
$EUL
Điều gì định nghĩa một vault BTC thực sự trustless?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
tham gia
英鸿³³₇
·
--
[Phát lại] 🎙️ Chuyện tình yêu hận thù của thị trường sơ cấp, đầu tư định kỳ BNB ở thị trường thứ cấp
02 giờ 17 phút 48 giây · 12.8k người nghe
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
giỢ hai nhóm quỹ cùng một loại tài sản, nằm cách nhau vài “click”, với không hề có sự liên kết nào giữa chúng cho đến bây giờ. Aave đang nắm giữ khoảng 5B USD WBTC và hầu như không biến động ở phía vay. Babylon nắm giữ từ 4B+ USD BTC đã đặt cọc, nhưng không kiếm được gì ngoài phần thưởng staking.
đó là “chiêu bài” thực sự nằm trong Temp Check của Babylon — không phải “BTC không cần tin cậy”, mà là việc khớp nguồn cung nhàn rỗi trên một nền tảng với tài sản thế chấp nhàn rỗi trên nền tảng khác.
Thiết kế Hub-and-Spoke của Aave trên V4 là thứ khiến điều này có thể xảy ra mà không cần Babylon chạm vào lõi pool cho vay của Aave. Hai Spokes mới triển khai dưới dạng các module tách biệt — Babylon sở hữu logic tài sản thế chấp BTC, trong khi Hub chính của Aave vẫn không bị ảnh hưởng bởi bất kỳ rủi ro nào do điều đó tạo ra.
đáng lưu ý: đây không phải một đề xuất của cộng đồng “trôi nổi” mà bị bỏ qua. Người sáng lập của Aave đã công khai ủng hộ nó, đồng thời chỉ đích danh phần triển khai Spoke như một mô hình mới cho V4 — không chỉ là thêm một danh sách tài sản khác.
vẫn đang ở giai đoạn Temp Check. ARFC và một cuộc bỏ phiếu on-chain đều phải diễn ra trước khi bất kỳ BTC nào thực sự được chuyển qua.
nếu sau khi phần này vượt qua quản trị mà cả hai pool vẫn tiếp tục “đắp chiếu” trong vài tháng, thì vấn đề chưa bao giờ nằm ở đường ống. mà nằm ở sự sẵn sàng/nhiệt huyết.
$DEXE
Điều quan trọng nhất là gì nếu việc này được triển khai?
giỢ hai nhóm quỹ cùng một loại tài sản, nằm cách nhau vài “click”, với không hề có sự liên kết nào giữa chúng cho đến bây giờ. Aave đang nắm giữ khoảng 5B USD WBTC và hầu như không biến động ở phía vay. Babylon nắm giữ từ 4B+ USD BTC đã đặt cọc, nhưng không kiếm được gì ngoài phần thưởng staking.
đó là “chiêu bài” thực sự nằm trong Temp Check của Babylon — không phải “BTC không cần tin cậy”, mà là việc khớp nguồn cung nhàn rỗi trên một nền tảng với tài sản thế chấp nhàn rỗi trên nền tảng khác.
Thiết kế Hub-and-Spoke của Aave trên V4 là thứ khiến điều này có thể xảy ra mà không cần Babylon chạm vào lõi pool cho vay của Aave. Hai Spokes mới triển khai dưới dạng các module tách biệt — Babylon sở hữu logic tài sản thế chấp BTC, trong khi Hub chính của Aave vẫn không bị ảnh hưởng bởi bất kỳ rủi ro nào do điều đó tạo ra.
đáng lưu ý: đây không phải một đề xuất của cộng đồng “trôi nổi” mà bị bỏ qua. Người sáng lập của Aave đã công khai ủng hộ nó, đồng thời chỉ đích danh phần triển khai Spoke như một mô hình mới cho V4 — không chỉ là thêm một danh sách tài sản khác.
vẫn đang ở giai đoạn Temp Check. ARFC và một cuộc bỏ phiếu on-chain đều phải diễn ra trước khi bất kỳ BTC nào thực sự được chuyển qua.
nếu sau khi phần này vượt qua quản trị mà cả hai pool vẫn tiếp tục “đắp chiếu” trong vài tháng, thì vấn đề chưa bao giờ nằm ở đường ống. mà nằm ở sự sẵn sàng/nhiệt huyết.
$DEXE
Điều quan trọng nhất là gì nếu việc này được triển khai?
Đúng một phần
#baby $BABY @BabylonLabs_io
Hôm qua tôi đọc lướt qua các ghi chú di chuyển từ Aave v3 sang v4, chủ yếu vì chán nản, và một câu từ giấy tờ về vault của Babylon đã đọng lại trong đầu sau khi tôi đóng tab: các điều kiện chi tiêu của một vault TBV, bao gồm cả hợp đồng đích, được cố định ngay thời điểm nó được tạo ra—đó là điều khiến nó trở nên “trustless” (không cần tin cậy). Không ai có thể chuyển hướng BTC sau đó nếu không có sẵn lộ trình đã được thỏa thuận trước. Ý nghĩa thầm lặng ở đây là: nếu Aave bao giờ lại di chuyển hợp đồng theo cách tương tự như vừa rồi từ v3 sang v4, thì một vault đang tồn tại không thể đi theo được; nó phải tự “unwind” (giải/đảo trạng thái) theo đúng timeline của Bitcoin và sau đó được tạo lại, trỏ tới đích mới, và điều đó lặp lại mỗi lần giao thức đích nâng cấp. Sự “trustless” này không hề miễn phí—nó được đánh đổi lấy tính cứng nhắc (rigidity), và có vẻ như không ai đang định giá điều đó. Tôi không tìm thấy thông tin công khai nào về việc Babylon hay Aave có kế hoạch công cụ để làm cho quá trình chuyển đổi này mượt hơn không. Đây không phải là chuyện vault trông an toàn ra sao vào ngày bạn tạo nó, mà là chuyện điều gì xảy ra vào ngày phía bên kia của nó buộc phải thay đổi.
$DEXE
Bù trừ/lợi hại lớn hơn ở đây là gì?
Hôm qua tôi đọc lướt qua các ghi chú di chuyển từ Aave v3 sang v4, chủ yếu vì chán nản, và một câu từ giấy tờ về vault của Babylon đã đọng lại trong đầu sau khi tôi đóng tab: các điều kiện chi tiêu của một vault TBV, bao gồm cả hợp đồng đích, được cố định ngay thời điểm nó được tạo ra—đó là điều khiến nó trở nên “trustless” (không cần tin cậy). Không ai có thể chuyển hướng BTC sau đó nếu không có sẵn lộ trình đã được thỏa thuận trước. Ý nghĩa thầm lặng ở đây là: nếu Aave bao giờ lại di chuyển hợp đồng theo cách tương tự như vừa rồi từ v3 sang v4, thì một vault đang tồn tại không thể đi theo được; nó phải tự “unwind” (giải/đảo trạng thái) theo đúng timeline của Bitcoin và sau đó được tạo lại, trỏ tới đích mới, và điều đó lặp lại mỗi lần giao thức đích nâng cấp. Sự “trustless” này không hề miễn phí—nó được đánh đổi lấy tính cứng nhắc (rigidity), và có vẻ như không ai đang định giá điều đó. Tôi không tìm thấy thông tin công khai nào về việc Babylon hay Aave có kế hoạch công cụ để làm cho quá trình chuyển đổi này mượt hơn không. Đây không phải là chuyện vault trông an toàn ra sao vào ngày bạn tạo nó, mà là chuyện điều gì xảy ra vào ngày phía bên kia của nó buộc phải thay đổi.
$DEXE
Bù trừ/lợi hại lớn hơn ở đây là gì?
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đăng nhập để khám phá thêm nội dung