Salman49

TẠI SAO MỘT SỰ KIỆN BLOCKCHAIN KHÔNG GIỐNG “FINALITY”

Trước đây tôi từng nghĩ rằng một sàn giao dịch chủ yếu cần biết khi nào một giao dịch blockchain xảy ra. Nhưng khi xem Dusk, tôi bắt đầu nghi ngờ điều đó. Nếu một giao dịch vẫn có thể thay đổi, tôi không chắc sàn giao dịch nên xem sự kiện đó như tiền đã “final”.

Đó là lý do RUES (Rusk Universal Event System) thu hút sự chú ý của tôi. Dusk cụ thể liệt kê RUES cho hạ tầng, indexers và các sàn giao dịch. Với tôi, phần thú vị nằm ở việc sàn làm gì sau khi nhận được sự kiện.

Vòng đời giao dịch của Dusk tách bạch các giai đoạn: included (đã đưa vào), executed (đã thực thi), confirmed (đã xác nhận) và finalized (đã final). Tài liệu của họ nói rằng cần theo dõi transaction đã được executed, kiểm tra lỗi, xác nhận rằng block đã finalized và re-listen nếu một block bị revert. Tôi hiểu vì sao điều này quan trọng: ghi có cho sàn quá sớm có thể biến một trạng thái tạm thời thành số dư thực.

Tôi cứ nghĩ về việc theo dõi hành trình của nhân viên giao hàng. Nếu kiện hàng của tôi hiển thị “đang trên đường giao”, tôi biết là nó đang di chuyển, nhưng tôi sẽ chưa đánh dấu là “đã giao”. Có lẽ tôi đang cẩn thận quá, nhưng tôi hiểu vì sao một sàn giao dịch lại muốn có cùng khoảng cách giữa “đang di chuyển” và “đã giao”.

Chi tiết về idempotency cũng khiến tôi dừng lại lần nữa. Dusk hướng dẫn các deposit scanners dùng Dusk transaction ID làm khóa idempotency thay vì memo, và ghi credit cùng checkpoint của block theo kiểu nguyên tử (atomically). Như vậy, nếu scanner bị crash và quét lại cùng một dải, thì giao dịch đó sẽ không trở thành một khoản deposit thứ hai.

Và giờ tôi lại tự hỏi liệu tôi đang nhìn RUES quá đơn giản. Nếu một sàn phải cân nhắc riêng rẽ về sự kiện, finality, việc revert và xử lý trùng lặp, thì phần “công việc thực sự” đang diễn ra sau khi blockchain nói rằng điều gì đó đã xảy ra là bao nhiêu? @Dusk #dusk $DUSK

VÌ SAO MINH BẠCH CÓ THỂ TRỞ THÀNH VẤN ĐỀ TRONG TÀI CHÍNH

Crypto đã khiến minh bạch trở thành câu trả lời hiển nhiên. Ai cũng thấy cùng một hoạt động, nên mọi người có thể tin vào cùng một bản ghi.
Nhưng tôi không chắc logic đó hoạt động theo cách tương tự trong các thị trường tài chính.

Nếu ai cũng có thể nhìn thấy một lệnh lớn, một vị thế lớn, hoặc những biến động nhạy cảm của một công ty trước khi mọi thứ hoàn tất, thì thông tin đó có thể làm thay đổi cách người khác hành xử. Minh bạch có thể giúp thị trường hiểu điều gì đã xảy ra, nhưng quá nhiều khả năng nhìn thấy cũng có thể làm lộ người thực hiện động thái.

Đó là lý do cách tiếp cận về quyền riêng tư của Dusk đã thu hút sự chú ý của tôi. Có vẻ như họ không coi quyền riêng tư chỉ đơn giản là che giấu mọi thứ. Hoạt động công khai có thể vẫn hiển thị, trong khi các giao dịch nhạy cảm có thể được giữ riêng tư, và vẫn có thể chia sẻ thông tin cụ thể khi một bên được ủy quyền cần đến.

Hedger khiến ý tưởng này còn thú vị hơn với tôi. Dusk đang xây dựng các luồng EVM bảo mật xung quanh nó, với mục tiêu giữ cho các hoạt động nhạy cảm ở chế độ riêng tư nhưng vẫn có thể kiểm chứng được. Hướng đi này cũng bao gồm nhiều hoạt động thị trường riêng tư hơn, thay vì đưa mọi chi tiết ra trước tất cả mọi người.

Kết luận của tôi khá đơn giản:
Một thị trường tài chính tốt có thể không cần thêm minh bạch. Nó có thể cần kiểm soát tốt hơn về việc ai được xem gì.

Vì minh bạch nên giúp mọi người xác minh thị trường.

Nó không nên tự động mang lại lợi thế cho mọi người tham gia so với những người còn lại. DYOR.
@Dusk #dusk $DUSK

Tôi cứ nghĩ hoàng hôn đã có quá nhiều lối đi. Rồi tôi tự hỏi “đơn giản” thật sự nghĩa là gì.

Khi đọc về hạ tầng blockchain, tôi nhận ra có một điều: chúng ta thường gọi một hệ thống là “đơn giản” khi kiến trúc nhìn có vẻ đơn giản. Một chuỗi, một luồng thực thi, ít bộ phận chuyển động hơn. Nghe có vẻ ổn. Nhưng rồi tôi bắt đầu tự hỏi: đơn giản cho ai?

Chính điều đó đã khiến tôi chú ý tới Dusk. Ban đầu, việc có một lối đi EVM và một lối đi native khiến tôi thấy như là một sự phức tạp không cần thiết. Tại sao không chỉ chọn một?

Sau đó tôi thấy cách Dusk tự so sánh. Các tích hợp native tùy biến có thể mất 6–12 tháng và tốn chi phí nhiều hơn tới 50× so với các triển khai bằng EVM, trong khi các triển khai EVM có thể hoàn thành trong vài tuần.

Điều đó khiến tôi nhìn vấn đề theo một cách khác.

Chi phí của một blockchain không phải lúc nào cũng nằm trong chính blockchain. Rất nhiều chi phí nằm xung quanh nó. Ví, sàn giao dịch, công cụ cho nhà phát triển, API, các hệ thống nội bộ—tất cả những kết nối “chán đời” nhưng bắt buộc phải hoạt động trước khi bất kỳ ai mới quan tâm đến công nghệ nằm bên dưới.

Và đây là phần tôi nghĩ chúng ta thường đánh giá thấp.

Nếu việc làm cho một chuỗi “đơn giản hơn” đồng nghĩa với việc mọi hệ thống bên ngoài phải làm việc nhiều hơn để kết nối với nó, thì chúng ta có thực sự loại bỏ độ phức tạp không? Hay chỉ là chuyển nó sang một nơi khác?

Vì vậy mà giờ đây tôi thấy kiến trúc của Dusk thú vị hơn. Không phải vì nó có hai lối đi, mà vì nó đặt ra một câu hỏi lớn hơn về cách xây dựng hạ tầng tài chính.

Có lẽ kiến trúc tốt nhất không phải là kiến trúc có ít lối đi nhất. Mà là kiến trúc giúp ít người phải “xây lại từ đầu” những thứ vốn đã hoạt động.

DYOR.

$DUSK
@Dusk
#dusk

TOKEN CÓ THỂ LÀ FUNGIBLE. NGƯỜI NẮM GIỮ NÓ KHÔNG NHẤT THIẾT.

Tôi cứ bị mắc kẹt vào một điểm khi nói về tài sản được quản lý trên chuỗi.

Hai người có thể nắm giữ cùng một loại chứng khoán.
Nhưng họ có thể không có cùng quyền lợi.

Thiết kế tài sản được quản lý của Dusk đưa các yếu tố về tính đủ điều kiện, thông tin xác thực danh tính, gắn ví và kiểm tra chuyển nhượng vào trong quy trình. Vì vậy, chỉ nắm giữ token chưa chắc đã đủ. Người nhận nó cũng có thể cần phải đáp ứng các quy tắc của tài sản.

Và điều này khiến tôi đặt câu hỏi về cách chúng ta nói về tính thanh khoản.

Thông thường, tôi hỏi:

“Có bao nhiêu tiền đang sẵn có?”

Nhưng có lẽ đó mới chỉ là một nửa câu chuyện.

Nếu câu hỏi đúng hơn là:

“Có bao nhiêu người thực sự được phép nhận tài sản này?”

Có thể sẽ có rất nhiều vốn đang chờ ở ngoài lề. Tuy vậy, nhóm người mua thực sự có thể vẫn còn nhỏ.

Citadel bổ sung thêm một lớp khác. Người tham gia có thể chứng minh các điều như nơi cư trú, nhóm tuổi hoặc tư cách được cấp phép thông qua việc tiết lộ có chọn lọc. Họ không nhất thiết phải phơi bày mọi thứ về bản thân.

Đó là chỗ mà mọi thứ trở nên thú vị đối với tôi.

Có lẽ vấn đề thanh khoản tiếp theo trong tài chính tokenized không phải là tìm đủ người mua.

Mà là tìm đủ người mua thực sự được phép trở thành chủ sở hữu.

@Dusk #dusk $DUSK

TÔI LÀM THEO NÚT “MUA” VÀO ĐẾN LÚC TRỜI TỐI. MỌI THỨ PHỨC TẠP NHANH CHÓNG.

Tôi thấy nút “Mua” trên Dusk Trade và thành thật mà nói, tôi nghĩ rằng, ừm, chắc đây chỉ là một thị trường mua bán token hóa khác.

Rồi tôi xem phải có những gì diễn ra xung quanh cái nút đó.

Trước khi tôi có thể mua một tài sản được quản lý, cần có KYC và điều kiện đủ tư cách. Ví của tôi phải kết nối. Phương thức thanh toán phải phù hợp với tài sản. Một số thông tin cần được giữ riêng tư, trong khi một số thông tin khác có thể cần được gửi tới tổ chức phát hành, sàn giao dịch hoặc một bên được ủy quyền khác. Và sau tất cả, giao dịch vẫn phải được hoàn tất (settle). Dusk Trade được thiết kế đúng cho loại quy trình như vậy, trong khi DuskDS đảm nhiệm phần thanh toán và tính cuối cùng (finality) bên dưới.

Điều đó khiến tôi phải dừng lại.

Thực ra, phần “token” không phải là thứ khó nhất.

Ai cũng có thể nói: “tài sản này giờ đã nằm trên chuỗi.” Những câu hỏi khó bắt đầu sau đó: Ai có thể mua nó? Ai có thể chuyển nó? Tổ chức phát hành được xem những gì? Khi nào khoản thanh toán thực sự được khớp với tài sản?

Đây cũng là lý do ý tưởng phát hành gốc (native-issuance) của Dusk làm tôi chú ý. Tài liệu của họ không coi một tài sản chỉ là một token nằm chồng lên một hệ thống cũ. Họ nhìn vào toàn bộ vòng đời — phát hành, lưu ký, giao dịch, thanh toán, công bố và báo cáo — và đặt câu hỏi rằng có bao nhiêu trong số đó thực sự có thể được đưa vận hành ngay quanh sổ cái (ledger).

Và Dusk Trade vẫn đang trong giai đoạn chưa ra mắt, nên tôi không có ý nói rằng mình đã dùng thị trường này rồi. Tôi đang xem hệ thống họ đang cố gắng xây dựng.

Bởi vì cái nút “Mua” nhỏ bé đó đang che giấu một câu hỏi lớn một cách bất ngờ:

Liệu các quy tắc xung quanh một tài sản tài chính có thể chuyển động lên chuỗi cùng chính bản thân tài sản đó không?

DYOR. @Dusk #dusk $DUSK

Ý TƯỞNG THÚ VỊ NHẤT CỦA TBV KHÔNG PHẢI NÚT BORROW

Phần thú vị nhất của TBV với tôi không phải là nút vay (borrow). Mà là thứ tự thanh lý (liquidation order). Trên public testnet hiện tại, TBV cố tình giữ các vault nhỏ: kích thước vault tối thiểu là 0.01 BTC, tối đa là 0.4 BTC, một vị thế có thể dùng tối đa 10 vault, hệ số đòn bẩy (BTC collateral factor) là 78%, và việc thanh lý bắt đầu khi health factor giảm xuống dưới 1.0. TBV cũng khóa BTC trên Bitcoin mà không cần bọc (wrapping) hay cầu nối (bridging), và Aave v4 là ứng dụng DeFi đầu tiên được đăng ký chạy trên nền tảng này.

Điểm khiến tôi chú ý là cách Babylon muốn bạn cấu trúc chính “BTC” đó. Tài liệu khuyến nghị tạo một vault hiến tế (sacrificial vault) trước và một vault được bảo vệ (protected vault) sau. Nếu việc thanh lý xảy ra, giao thức sẽ lần lượt duyệt các vault theo thứ tự và chỉ thu giữ đúng lượng tối thiểu cần thiết để khôi phục health factor mục tiêu. Vault được bảo vệ có thể vẫn được giữ nguyên, không bị đụng tới. Thậm chí sau này bạn có thể sắp xếp lại thứ tự các vault nếu điều kiện thị trường thay đổi. Cách này có cảm giác khác rất nhiều so với mô hình tài sản thế chấp thông thường kiểu “chỉ cần một thay đổi nhỏ là mọi thứ biến mất”.

Vì vậy mà TBV với tôi có vẻ “to” hơn một bản demo cho vay. Một vault BTC được tạo cho một ứng dụng tại thời điểm peg-in và sau đó không thể chuyển sang ứng dụng khác. Do đó, tài sản thế chấp không chỉ đơn thuần là thứ có thể đem đi vay. Nó còn được “dàn dựng” với một mục đích. Tôi cứ quay lại phần này nhiều hơn màn hình borrow: không phải là BTC có thể được dùng hay không, mà là nó có thể sống sót được bao nhiêu khi vị thế bắt đầu đi sai hướng. DYOR.

@BabylonLabs_io #baby $BABY

TẠI SAO TRUSTLESS VẪN PHỤ THUỘC VÀO CÁCH SẢN PHẨM ĐƯỢC THIẾT KẾ

Quản trị viên quỹ.

Đó là câu khiến tôi phải chậm lại.
Ý tưởng của Babylon rất dễ hiểu. Trustless Bitcoin Vaults (TBV) được thiết kế để Bitcoin vẫn nằm trên Bitcoin, nhưng vẫn có thể được sử dụng trong các ứng dụng tài chính mà không cần bọc (wrapping) hay từ bỏ quyền lưu ký. Đó là phần mà tài liệu chính thức giải thích rất rõ ràng.

Rồi tôi chuyển sang phần tích hợp GoMining dự kiến.

Thông báo nói rằng người dùng tổ chức được kỳ vọng sẽ khóa BTC thông qua TBV, vay dựa trên đó, và phân bổ số tiền vay vào các sản phẩm khai thác (mining) do GoMining quản lý. Đồng thời, nó cũng nói rằng phương tiện này dự kiến sẽ được cấu trúc như một quỹ được token hóa của GoMining, với Quản trị viên quỹ độc lập, Tổ chức lưu ký (Custodian) và Kiểm toán viên (Auditors). Cùng lúc đó, nó lại nói rằng một tích hợp cho người dùng bán lẻ chỉ đang được cân nhắc.

Đó là lúc câu hỏi của tôi thay đổi.

Nó không còn nằm ở việc TBV có trustless hay không. Mà là cách quỹ sẽ tương tác với TBV.

Thông báo công khai giải thích mục tiêu, nhưng không mô tả đầy đủ quy trình dành cho người dùng bán lẻ. Nó không công khai cho thấy người dùng bán lẻ trong tương lai sẽ chuyển từ ứng dụng GoMining sang TBV như thế nào, hoặc trải nghiệm đó có khác với cấu trúc dành cho tổ chức hay không.

Có thể những chi tiết đó sẽ được công bố khi sản phẩm dành cho bán lẻ ra mắt. Hiện tại, tôi đơn giản là không thể tự xác minh chúng từ tài liệu công khai.

Celsius đã thay đổi một thói quen của tôi. Bất cứ khi nào tôi thấy các cụm từ như Quản trị viên quỹ (Fund Administrator) hoặc Tổ chức lưu ký (Custodian), tôi lại dành nhiều thời gian đọc cấu trúc pháp lý hơn là phần nói về phần thưởng.

Trong các sản phẩm kết hợp thiết kế giao thức với sản phẩm tài chính, những tài liệu đó thường trả lời các câu hỏi khác.

Vì vậy tôi không chờ một APY cao hơn.

Tôi đang chờ tài liệu giải thích luồng cho người dùng bán lẻ: từ thao tác chạm đầu tiên trong ứng dụng cho đến kho lưu trữ BTC cuối cùng. #baby $BABY @BabylonLabs_io

NFA.DYOR.

Tại sao Staking BTC + Finality Providers làm cho danh tiếng của hạ tầng trở nên đo lường được

Tôi mở tài liệu Babylon vào thứ Năm tuần trước với kỳ vọng đây lại là một “stake BTC, nhận lợi suất” quen thuộc. Nhưng tôi lại bị Finality Providers cuốn đi. Tôi đã lần theo một lần ủy quyền từ đầu đến cuối trên testnet và nhận ra đây không phải là staking thụ động. Chủ sở hữu Bitcoin đang tự tay chọn ai sẽ vận hành hạ tầng.

BTC stake của bạn không “lên sóng” ngay khi bạn khóa nó. Nó đi vào MsgCreateBTCDelegation, nằm trong BTCDelegationRegistry, chờ 6 xác nhận BTC, rồi mới gắn với một Finality Provider cụ thể trước khi bất kỳ quyền biểu quyết nào được kích hoạt. Mối liên kết đó không phải là lời quảng bá cho đẹp. Nó là trạng thái của giao thức. Bạn có thể truy vấn nó.

Rồi EOTS mới thực sự khiến tôi hiểu ra. Nếu một FP ký đôi, bạn không nộp đơn khiếu nại lên quản trị. Giao thức sẽ trích xuất khóa bí mật của họ bằng mật mã học. Bằng chứng, không phải tranh cãi. QueryFinalityProviders đã hiển thị pubkey, sức mạnh biểu quyết, trạng thái bị slash. Tôi tiếp tục tìm kiếm một “điểm danh tiếng” và nhận ra Babylon không cần nó. Nó ghi lại hành vi thô: thời gian hoạt động, bị slash, luồng ủy quyền. Danh tiếng được xây từ đó.

Điều này giống như chọn AWS hay GCP. Không ai tin khẩu hiệu. Bạn kiểm tra sự cố, thời gian uptime, MTTR. Babylon chưa chấm điểm các FP, nhưng nó đưa dữ liệu khách quan lên chain thay vì ý kiến trên Discord.

Sau đó tôi không còn bận tâm đến lợi suất BTC nữa. Tôi bắt đầu theo dõi stake của mình gắn với FP nào, vì hành động của họ là công khai, có thể xác minh, có thể so sánh. Đó là trách nhiệm giải trình của hạ tầng mà bạn có thể đo lường được chứ không chỉ hứa suông bằng $BABY .

Nguồn: Tài liệu Babylon tháng 11 năm 2025. Không phải lời khuyên tài chính. Tự nghiên cứu (DYOR). @BabylonLabs_io #baby $BABY

TẠI SAO BABYLON CHIA VIỆC XÁC THỰC THÀNH CÁC GIAI ĐOẠN CHUYÊN BIỆT THAY VÌ LÀM TẤT CẢ MỌI THỨ NGAY MỘT LÚC

Tôi đã mở <a>@BabylonLabs_io docs</a> vì muốn hiểu về staking Bitcoin. Kỳ lạ là, phần staking lại không phải thứ đọng lại trong đầu tôi. Tôi bị mắc kẹt vào một thứ nhỏ hơn nhiều. Tôi đang theo dõi một checkpoint và nhận thấy nó không bao giờ đi thẳng đến Bitcoin. Nó cứ chuyển động từ phần này của giao thức sang phần khác.

Ban đầu tôi nghĩ mình đã bỏ sót điều gì đó. Tại sao không để một thành phần làm mọi thứ? Nhưng càng xem nhiều sơ đồ, tôi càng thấy nó có vẻ rất chủ ý. Epoching hoàn tất trước. Nó chờ một epoch kết thúc và giữ cho tập validator ổn định trước khi một checkpoint thậm chí còn được tạo. Xét rằng Bitcoin chỉ tạo một block khoảng mỗi 10 phút, việc đẩy mọi sự kiện của giao thức lên đó sẽ chẳng mấy hợp lý.

Rồi checkpoint lại tiếp tục. Module Checkpointing thu thập các chữ ký BLS vào một checkpoint duy nhất. Một Vigilante gửi nó lên Bitcoin bằng OP_RETURN. Sau đó, BTC Light Client kiểm tra các header của Bitcoin một cách độc lập. Tôi cứ mong sẽ có một nơi nơi mọi thứ được gom lại, nhưng Babylon thực sự không hoạt động theo kiểu đó.

Cũng chuyện tương tự xảy ra khi tôi đi đến phần còn lại của kiến trúc. BTC Staking không hề cố gắng xác thực các checkpoint. Finality Providers không phải đang quản lý việc ủy quyền. EOTS cũng không phải là một module staking khác. Mọi phần dường như đều thoải mái khi chỉ làm một việc rồi rời đi. Giao thức không bao giờ yêu cầu một thành phần phải biết mọi thứ.

Tôi nghĩ đó là lúc kiến trúc cuối cùng cũng trở nên rõ ràng với tôi. Không phải vì tôi hiểu thêm một module khác, mà vì tôi ngừng tìm kiếm “module chính”. Mỗi khi một mảnh hoàn thành công việc của mình, thì một mảnh khác âm thầm đảm nhận tiếp. Cuối cùng tôi lại dành nhiều thời gian để nhìn các chỗ bàn giao đó hơn là bản thân các thành phần.

DYOR.

#baby $BABY

TẠI SAO BITCOIN TIMESTAMPING + CHECKPOINTING TÁCH “FINALITY” THÀNH HAI LỚP

Tôi luôn nghĩ finality thì đơn giản. Khi đã hoàn tất thì coi như đã xong.

Nhưng rồi tôi đọc về cách Bitcoin Timestamping Protocol và Checkpointing phối hợp với nhau. Điều đó khiến tôi nhìn nhận finality theo một cách khác.

Mỗi blockchain đều muốn xác nhận nhanh. Người dùng cũng muốn có niềm tin rằng lịch sử sẽ không thay đổi về sau. Làm được cả hai với cùng một hệ thống thì khó hơn bạn tưởng.

Babylon Labs không tìm cách làm Bitcoin nhanh hơn. Họ giao cho Bitcoin một vai trò khác.

Khi một epoch đạt đến finality thông qua Finality Providers, Babylon Chain vẫn tiếp tục chạy. Module x/checkpointing sẽ tạo ra một epoch Merkle root. Bitcoin Timestamping Protocol chỉ ghi cam kết mật mã (cryptographic commitment) đó lên Bitcoin bằng cách sử dụng OP_RETURN. Bitcoin không cần mọi block hay mọi giao dịch từ epoch đó.

Đó là phần khiến tôi thấy thú vị.

Nếu mọi bước đều phải chờ Bitcoin, thì mọi chuỗi được kết nối cũng sẽ bị chậm lại. Babylon tránh điều đó bằng cách để mạng lưới tiến hành trước. Bitcoin được dùng để “neo” checkpoint đã hoàn tất sau đó.

Với tôi, đó chính là ý tưởng cốt lõi đằng sau thiết kế này.
Checkpointing không chỉ nhằm tiết kiệm dung lượng block của Bitcoin. Đó là việc quyết định khi nào Bitcoin nên được đưa vào. Việc phối hợp nhanh diễn ra trên Babylon Chain. Bitcoin giúp bảo vệ bản ghi sau khi công việc đã được thực hiện.

Vì vậy, tôi nghĩ Bitcoin Timestamping Protocol và Checkpointing không chỉ cải thiện finality. Chúng tách hai công việc khác nhau mà nhiều blockchain cố gắng làm bằng cùng một quy trình.

DYOR.

#baby $BABY @BabylonLabs_io

Cuộc chiến được Bitcoin bảo vệ mà không ai sẵn sàng

Tôi đã mở tài liệu của Babylon vì tôi muốn hiểu một điều.

Bitcoin-secured thực sự có nghĩa là gì?

Câu trả lời còn đơn giản hơn những gì tôi mong đợi. Bitcoin giúp bảo vệ mạng. Chuỗi vẫn chạy mã, ứng dụng và các bản nâng cấp của riêng nó. Đó là hai công việc khác nhau.

Rồi một câu hỏi khác lại xuất hiện trong đầu tôi.

Nếu một chuỗi sử dụng bảo mật được Bitcoin hậu thuẫn bị hack, thì danh tiếng của ai sẽ lãnh hậu quả?

Là chuỗi?

Hay là Bitcoin?

Chính ở đây tôi nghĩ mọi thứ bắt đầu trở nên rắc rối.

Hãy tưởng tượng tiêu đề đầu tiên:

Chuỗi được Bitcoin-secured bị hack.

Phần lớn mọi người sẽ không mở bài viết. Họ sẽ không kiểm tra xem vấn đề đến từ hợp đồng thông minh, mã code riêng của chuỗi hay lớp bảo mật được Bitcoin hậu thuẫn. Họ chỉ nhớ đúng hai từ: Bitcoin và bị hack.

Vì vậy, tôi cho rằng thách thức lớn nhất không phải là kỹ thuật.

Mà là ý nghĩa của hai từ đó.

Tài liệu giải thích Bitcoin giúp bảo mật mạng như thế nào. Tài liệu không nói rằng Bitcoin sửa mọi lỗi hay kiểm soát những gì nhà phát triển xây dựng trên lớp đó.

Đó là những chuyện khác nhau.

Công nghệ có thể hoạt động đúng như cách nó được thiết kế, nhưng tiêu đề vẫn có thể kể một câu chuyện hoàn toàn khác.

Có lẽ tôi đang nghĩ xa quá.

Nhưng crypto chưa bao giờ chỉ tranh luận về code.
Chúng ta đã mất nhiều năm tranh cãi về những thuật ngữ như Bitcoin thật, Layer 2, và phi tập trung.
Tôi sẽ không ngạc nhiên nếu Bitcoin-secured trở thành thuật ngữ tiếp theo. _DYOR.

#baby $BABY @BabylonLabs_io

Ai sẽ giàu lên khi bạn nộp phạt? Babylon nói rằng không ai

Tuần trước tôi nhận một giấy phạt ₹500. Tôi vượt đèn đỏ. Tiền đó đi về phía chính phủ.

Sau đó ngân hàng của tôi lấy ₹400 cho khoản EMI trả chậm 1 ngày. Ngày đến hạn được giấu trong phần chữ nhỏ. Sai lầm của tôi lại trở thành lợi nhuận của họ.

Hôm đó tôi nhận ra điều gì đó. Nếu ai đó kiếm lời từ sai lầm của tôi, họ sẽ không bao giờ giúp tôi tránh nó.

Rồi tôi bắt đầu dùng Babylon. Babylon cho phép bạn “stake” Bitcoin của mình để giúp bảo mật các blockchain khác. Bạn nhận phần thưởng khi làm đúng quy tắc.

Nhưng nếu bạn vi phạm quy tắc thì sao? Babylon có một hình phạt gọi là “slashing”.

Tài liệu của Babylon nêu: nếu một validator gian lận, Bitcoin đã stake của họ sẽ bị slashed. Slashed có nghĩa là bị đốt. Tài liệu ghi rõ—Bitcoin đó không chuyển cho đội ngũ Babylon. Không chuyển cho người dùng khác. Nó biến mất mãi mãi.

Đây là điểm khác biệt then chốt.

Với giấy phạt giao thông của tôi, chính phủ được lợi. Với ngân hàng của tôi, ngân hàng được lợi. Vì vậy họ sẽ hưởng lợi khi tôi vấp ngã.

Còn với Babylon, không ai kiếm lời từ hình phạt. Bitcoin bị hủy đi. Vì thế lý do duy nhất của quy tắc này là để giữ hệ thống an toàn, không phải để kiếm tiền.

Một hệ thống mà hình phạt không tạo ra “người thắng” là một hệ thống được xây trên niềm tin.

Giờ trước khi tôi dùng bất kỳ ứng dụng hay dịch vụ nào, tôi tự hỏi: "Ai sẽ nhận tiền nếu tôi mắc sai lầm?"

Nếu câu trả lời là "công ty", tôi không tin.
Nếu câu trả lời là "không ai", giống như Babylon, tôi biết quy tắc này là minh bạch. #baby $BABY @BabylonLabs_io

BTC của tôi, Quy tắc của tôi: Vụ rút 5B USD đã chứng minh điều đó

Tôi chỉ đang kiểm tra Babylon thì thấy 14.929 BTC đang được đưa vào giai đoạn unbonding (rút/giải khóa). Tôi muốn biết rốt cuộc số BTC đó sẽ quay trở lại như thế nào.

Lombard đang chuyển sang các Finality Providers (nhà cung cấp tính cuối) mới và TVL của Babylon đã giảm từ 3,97B USD xuống còn 2,68B USD. Thay vì chỉ nhìn vào TVL, tôi mở tài liệu để xem quy trình rút.

Tài liệu cho biết BTC sẽ trở nên có thể chi tiêu sau khoảng 301 block Bitcoin, tương đương gần hai ngày. Lombard cũng nói rằng BTC chỉ di chuyển sang các provider mới sau khi unbonding.

Sau đó tôi kiểm tra các quy tắc slashing (phạt cắt). Một provider không bị slashed chỉ vì nó chuyển sang provider khác. Chỉ xảy ra slashing nếu nó ký hai block khác nhau ở cùng một độ cao (height). Tôi kiểm tra lại quá trình di chuyển lần nữa vì muốn xem có BTC nào thực sự bị đốt (burned) hay không. Tôi không tìm thấy bất kỳ bằng chứng nào cho điều đó.

Babylon vẫn còn 68.500+ BTC đang được stake (đặt cược), và Lombard cùng Solv vẫn đang nắm giữ khoảng 85% trong số đó.

DYOR.

#baby $BABY @BabylonLabs_io

Tôi đã ngừng chia sẻ Bitcoin của mình

Việc vay mượn rất dễ hiểu.

Tôi cũng không mất nhiều thời gian ở đó.

Một câu từ phần khác cứ kéo tôi quay lại. Nó không phải là đang giải thích tôi có thể làm gì với Bitcoin. Nó là giải thích cách Babylon từ chối xử lý Bitcoin trước khi mọi thứ khác xảy ra.

Cách diễn đạt trông có vẻ bình thường.

"Bitcoin của bạn không trộn lẫn với bất kỳ ai khác."

Tôi đọc nó, lướt qua, rồi quay lại lần nữa. Nếu việc tách Bitcoin của từng người dùng sẽ tạo ra nhiều công việc hơn, thì hẳn là phải có một lý do. Không ai làm một hệ thống khó hơn mà không nhận lại điều gì.

Tài liệu không trả lời câu hỏi đó bằng một đoạn văn duy nhất. Nó trả lời thông qua kiến trúc. Mỗi người dùng sẽ có một vault Taproot riêng. Không có số dư dùng chung chờ sẵn ở phía sau.

Rồi quy mô bắt đầu thay đổi cách tôi nhìn nhận quyết định đó.

56.853 BTC đã nằm sẵn trong kiến trúc vault này. Đó là một hệ thống đang vận hành, không phải là một khái niệm. Cũng vào khoảng thời gian đó, a16z đã cam kết 15 triệu USD để giúp xây dựng Trustless Bitcoin Vaults. Những con số đó không cho tôi thấy thiết kế là đúng.

Chúng cho tôi thấy thiết kế xứng đáng được xem xét lần nữa.

Đó là lúc tôi quay lại từ đầu.

Nếu chỉ nói về việc vay mượn, thì việc có một vault lớn duy nhất hẳn đã là câu chuyện dễ kể hơn. Babylon không đi theo hướng đó. Họ chọn giữ Bitcoin của từng người dùng tách riêng trước khi nói về các khoản vay, thanh khoản hay bất cứ điều gì khác.

Tôi ngừng xem điều đó như một tính năng của vault.

Mọi thứ sau đó bắt đầu trông giống như một hệ quả của quyết định duy nhất ấy.@BabylonLabs_io #baby $BABY

Babylon không xây dựng một giao thức staking. Nó đang xây dựng một thị trường để bảo mật Bitcoin.

Phần lớn mọi người mô tả Babylon như một giao thức staking dành cho Bitcoin, nhưng sau khi xem qua kiến trúc, tôi không nghĩ staking là câu chuyện chính.

Staking là cơ chế, nhưng không phải mục tiêu cuối cùng.

Ý tưởng lớn hơn là chuyển Bitcoin thành bảo mật kinh tế mà các mạng lưới bên ngoài có thể sử dụng mà không cần BTC rời khỏi chính Bitcoin.

Thay vì yêu cầu người dùng bridge hoặc wrap BTC, Babylon giữ Bitcoin trên chuỗi gốc của nó trong khi cho phép các BSN kế thừa năng lực bảo mật kinh tế. Người nắm giữ BTC cung cấp bảo mật, các Finality Providers điều phối nó, và các BSN tiêu thụ.

Lúc đó, hệ thống giống một thị trường phân bổ bảo mật hơn là một giao thức staking truyền thống.

Phần thú vị hơn là thiết kế của Babylon đi xa hơn việc tạo lợi suất BTC đơn thuần. Khi ngày càng có nhiều BSN tích hợp, cùng một lượng stake Bitcoin cuối cùng có thể bảo mật nhiều mạng lưới thông qua multi-staking, tạo ra các luồng phần thưởng bổ sung mà không cần chuyển BTC ra khỏi chuỗi.

Nếu mô hình đó mở rộng, Bitcoin sẽ không còn giống như tài sản thế chấp “ngủ yên” mà bắt đầu giống như bảo mật dùng lại được và dùng chung.

Đó là điều mà hầu hết mọi người bỏ lỡ.

Gọi Babylon là “thị trường bảo mật” vẫn là một cách diễn giải chứ chưa phải ngôn ngữ chính thức của giao thức. Nhưng kiến trúc ngày càng hỗ trợ cách diễn giải đó: các nhà cung cấp bảo mật, các vận hành viên và người tiêu dùng được phối hợp với nhau thông qua Babylon Genesis.

Toàn bộ luận điểm phụ thuộc vào việc liệu các BSN có thực sự đòi hỏi bảo mật được bảo chứng bằng Bitcoin ở quy mô lớn hay không. Nếu không có mức độ áp dụng đáng kể, kiến trúc sẽ vẫn mang tính lý thuyết hơn là giá trị kinh tế.

Nhưng nếu sự áp dụng đến, Babylon có thể cuối cùng sẽ được nhớ đến không phải như một giao thức staking, mà như hệ thống đã biến Bitcoin thành hạ tầng bảo mật dùng chung cho nền kinh tế crypto rộng lớn hơn.

Nguồn: Luận điểm Babylon Nguồn: Staking Bitcoin Nguồn: Staking Bitcoin là gì Nguồn: Babylon: Một cách tiếp cận mang tính đột phá để mở rộng Bitcoin

#baby $BABY @BabylonLabs_io