三和社區-老葉

#dusk $DUSK @Dusk
Cách cơ bản nhất để ngăn chặn việc lạm dụng trên public chain là phí Gas: logic càng phức tạp khi thực thi thì phí càng cao. Tiền đề của cơ chế này là mạng có thể hiểu một giao dịch đã thực hiện bao nhiêu phép tính. Nhưng nếu chính logic của hợp đồng là bí mật, thì tiền đề đó còn đứng vững không? Đây là chi tiết kỹ thuật mà tôi muốn chất vấn lần này.

Với tư cách là một blockchain Layer-1, Dusk Network hỗ trợ tiêu chuẩn hợp đồng bảo mật bí mật (XSC). Khi thực thi smart contract bí mật, các chi tiết của quá trình chuyển đổi trạng thái được bọc trong các bằng chứng không kiến thức. Bên xác thực bên ngoài chỉ kiểm tra xem bằng chứng có hợp lệ hay không, chứ không kiểm tra từng dòng hợp đồng đã thực hiện những phép tính nào. Vấn đề là, riêng việc tính phí thường cần biết chính xác lượng tính toán, ví dụ đã đọc/ghi trạng thái bao nhiêu lần, chạy bao nhiêu vòng lặp. Trong bối cảnh bí mật, người xác thực có thể không thể thống kê trực tiếp như với hợp đồng công khai.

Mâu thuẫn nằm ở đây: Nếu cơ chế tính phí nhượng bộ, chuyển sang mức phí cố định hoặc ước lượng thô, thì người dùng độc hại có thể thiết kế những hợp đồng có lượng tính toán vượt xa chi phí—từ đó dùng chi phí tương đối thấp để “nhồi” tài nguyên tính toán của người xác thực, tạo thành rủi ro tấn công từ chối dịch vụ mang tính che giấu. Nhưng nếu cơ chế tính phí bắt buộc phải khớp chính xác với lượng tính toán, thì lại đồng nghĩa với việc gián tiếp rò rỉ thông tin về độ phức tạp của hợp đồng, mâu thuẫn với mục tiêu bảo vệ quyền riêng tư.

Vấn đề này không phải là tiêu chuẩn XSC không làm được, mà là giữa độ chính xác của tính phí và mức độ mạnh của quyền riêng tư, chắc chắn phải tìm một điểm dung hòa. Điểm dung hòa đó nên được thiết kế ra sao sẽ ảnh hưởng trực tiếp đến độ ổn định của smart contract bí mật trong điều kiện chịu tải thực tế của mạng.

$DUSK liệu có thể—mà không tiết lộ chi tiết phép tính—vẫn khiến cơ chế Gas có hiệu quả trong việc ngăn chặn lạm dụng hay không, theo tôi, chính là chi tiết then chốt để tiêu chuẩn XSC có thể chịu được các kịch bản có mức độ đồng thời cao.

#dusk $DUSK @Dusk
Tài chính truyền thống coi trọng “tính chắc chắn”. Một giao dịch hoàn tất nghĩa là hoàn tất, không có mối lo rằng vài phút sau có thể bị hủy/rollback. Tuy nhiên, nhiều blockchain lại dùng tính cuối cùng mang tính xác suất; về mặt lý thuyết, các khối vẫn có thể bị sắp xếp lại (reorg), chỉ là xác suất giảm dần theo thời gian. Chính khoảng chênh lệch này là nơi các tổ chức tài sản khi muốn đưa lên chuỗi dễ bị kẹt nhất—và cũng là chủ đề tôi muốn phân tích lần này.

Dusk Network, với tư cách là một blockchain Layer-1, sử dụng cơ chế đồng thuận mang tên Succinct Attestation, là một biến thể của chứng minh quyền sở hữu (proof-of-stake). Khác với thiết kế phải chờ xác nhận thêm vài khối và dựa vào việc “chồng” niềm tin theo xác suất, mục tiêu của Succinct Attestation là giúp khối đạt được tính cuối cùng xác định (deterministic finality) trong thời gian rất ngắn. Khi một khối đã được các bên xác thực (validators) bỏ phiếu xác nhận, thì sẽ không còn bị lật lại.

Tách ra để xem, cơ chế này dựa vào việc bỏ phiếu theo nhiều tầng của validators: một phần validators trước tiên hình thành đồng thuận sơ bộ, rồi do một tầng validators khác thực hiện xác nhận cuối cùng. Cả quy trình được nén lại chỉ trong vài giây, không cần phải chờ hàng chục phút như một số blockchain khác mới dám nói rằng giao dịch này thật sự đã được “chốt”.

Thiết kế này thực sự đi kèm với hợp đồng thông minh bảo mật (confidential smart contract). Nếu nội dung giao dịch vốn đã mang tính bí mật, thì khi các tổ chức tài chính thực hiện thanh toán/bù trừ (clearing) hoặc quyết toán (settlement), họ càng không thể chấp nhận sự không chắc chắn kiểu “giao dịch này có thể vẫn bị rollback”. Tính cuối cùng nhanh đồng nghĩa với việc đặt nền tảng hạ tầng cho chuẩn XSC, và hai thứ kết hợp lại mới phù hợp hơn với yêu cầu “giao dịch là hoàn tất” trong tài chính truyền thống.

Thiết kế đồng thuận $DUSK không chỉ đơn thuần theo đuổi tốc độ, mà là đưa thẳng “tính chắc chắn” mà các tình huống tài chính cần vào lớp nền tảng của giao thức. Tôi cho rằng cách nghĩ này sát với nhu cầu ứng dụng thực tế hơn nhiều so với việc chỉ hô khẩu hiệu TPS cao.

#dusk $DUSK @Dusk
Nhiều người khi nhắc đến “chuỗi quyền riêng tư” thường trực giác nghĩ rằng đó là “mọi giao dịch đều được ẩn đi”, nhưng thiết kế của Dusk thực ra không đơn giản chỉ một hướng. Trong bản whitepaper, mô hình giao dịch được tách thành hai tuyến, và chính thiết kế song song này là điểm đáng để mổ xẻ.

Trước hết, nói về góc độ phổ cập. Dusk Network là một blockchain Layer-1, đồng thời hỗ trợ hai chế độ giao dịch: một là giao dịch bí mật, trong đó số tiền và các bên tham gia đều được che giấu; tính hợp lệ được xác minh bằng bằng chứng không kiến thức. Tuyến này kết hợp với chuẩn hợp đồng bảo mật mật (XSC), phục vụ các bối cảnh tài chính cần quyền riêng tư; tuyến còn lại là giao dịch minh bạch công khai, trạng thái được hiển thị thẳng trên blockchain, ai cũng có thể tra cứu, đi theo mô hình tài khoản truyền thống. Nói cách khác, Dusk không bắt tất cả mọi người phải dùng chế độ riêng tư, mà cho phép cả hai trạng thái—bí mật và công khai—cùng tồn tại trên một blockchain.

Điểm mâu thuẫn nằm ở đây. Thiết kế song song nghe có vẻ linh hoạt, nhưng để hai trạng thái có thể “tương tác/liên thông”, thì bản thân đó đã là bài toán kỹ thuật khó: nếu tài sản trong tài khoản công khai muốn chuyển vào hợp đồng thông minh bí mật, hoặc kết quả từ hợp đồng bí mật cần phản ánh sang trạng thái công khai, thì giữa chúng cần một cơ chế chuyển đổi để đảm bảo quá trình không làm lộ quyền riêng tư, đồng thời không phá vỡ tính xác minh của trạng thái công khai. So với việc chỉ chọn một chế độ và làm đến cùng, độ phức tạp sẽ tăng gấp đôi.

Một vấn đề thực tế khác là trải nghiệm người dùng. Người dùng phổ thông sẽ phải làm thế nào để biết trong tình huống nào nên dùng giao dịch bí mật, và trong tình huống nào dùng giao dịch công khai? Nếu ngưỡng chuyển đổi của chế độ song song quá cao, đa số người có thể sẽ chỉ chọn dùng chế độ công khai. Khi đó, các kịch bản được dùng hợp đồng thông minh bí mật liệu có bị giới hạn trong nhóm người dùng/đơn vị rất ít, không thể lan rộng ra hệ sinh thái nói chung hay không?

$DUSK Liệu có thể biến “độ linh hoạt” của thiết kế song song thành một trải nghiệm sản phẩm thực sự dễ dùng, thay vì để sự phức tạp trở thành rào cản cho việc áp dụng—tôi nghĩ đây là trọng tâm cần theo dõi ở giai đoạn tiếp theo.

#dusk $DUSK @Dusk
Rủi ro dễ bị bỏ qua nhất của hệ thống chứng minh không kiến thức (ZK) không nằm ở hiệu năng, mà nằm ở chính bản thân mạch (circuit). Bất kỳ hợp đồng bí mật nào được “lót nền” bằng các công nghệ kiểu ZK-SNARK đều có đằng sau một bộ logic mạch. Khi đã triển khai và đưa vào vận hành, việc thay đổi sẽ không hề đơn giản. Đây là chi tiết kỹ thuật mà tôi đặc biệt quan tâm khi xem tài liệu của Dusk.

Dusk Network định vị là một blockchain lớp bảo mật cho ứng dụng tài chính. Là một chuỗi Layer-1, nền tảng hỗ trợ gốc chuẩn hợp đồng an toàn bí mật (XSC). Độ đúng đắn của các hợp đồng thông minh bí mật phụ thuộc vào việc thiết kế mạch bên dưới có hoàn toàn không tồn tại lỗ hổng hay không. Với hợp đồng thông minh truyền thống, nếu viết sai logic thì ít nhất các kiểm toán viên bên ngoài có thể đọc mã nguồn, theo dõi luồng thực thi để tìm ra vấn đề; nhưng với hợp đồng bí mật, trạng thái bản thân đã được mã hóa, nên nếu thiết kế mạch có khiếm khuyết, bên ngoài rất khó phát hiện bất thường chỉ dựa vào thông tin công khai.

Về mặt kỹ thuật, điều tôi còn khá hoài nghi là: khi chuẩn XSC trong tương lai cần nâng cấp, ví dụ thêm tính năng mới hoặc vá lỗ hổng, thì những thay đổi ở cấp độ mạch này sẽ được đảm bảo thế nào để không phá hỏng các hợp đồng bí mật đã được triển khai sẵn? Thông thường, việc nâng cấp hợp đồng thông minh chỉ là thay logic và triển khai lại. Nhưng với các hệ thống liên quan đến mạch chứng minh không kiến thức, thường cần phải thiết lập tin cậy lại (trusted setup), quy trình phức tạp; chỉ cần sơ suất cũng có thể vô tình đưa thêm các giả định an ninh mới.

Một vấn đề thực tế khác là ngưỡng kiểm toán. Nhân sự có thể hiểu được mạch ZK và đồng thời hiểu logic của hợp đồng tài chính vốn đã rất hiếm. Khi hợp đồng thông minh bí mật “chồng” hai lĩnh vực này lên nhau, các đội sẵn sàng và có năng lực thực hiện kiểm toán sâu sẽ càng ít hơn. Nếu hệ sinh thái kiểm toán không theo kịp, e rằng khi các tổ chức cần giao tài sản giá trị lớn cho các hợp đồng theo chuẩn XSC, họ vẫn sẽ phải tiếp tục quan sát.

$DUSK Điều thực sự cần chứng minh không phải là liệu có thể tạo ra được hợp đồng bí mật hay không, mà là liệu kiến trúc mạch này, dưới áp lực của quá trình lặp nâng cấp dài hạn và kiểm toán, có thể duy trì được sự ổn định và đáng tin cậy hay không.

#dusk $DUSK @Dusk
Các trang web phân tích dữ liệu trên chuỗi có thể cho bạn biết bất kỳ một blockchain công khai nào TVL, số lượng địa chỉ hoạt động và luồng chuyển tiền—đây là cách nền tảng để ngành crypto xây dựng niềm tin: người dùng không cần tin lời ai, cứ tự mình tra cứu trên chuỗi là được. Nhưng nếu một chuỗi ngay từ lớp giao thức đã ẩn nội dung giao dịch, thì phương thức xác minh này còn giữ nguyên ý nghĩa không? Đây là câu hỏi tôi nảy ra khi đọc lại tài liệu về Dusk.

Dusk Network định vị bản thân là một blockchain riêng tư dành cho các ứng dụng tài chính. Là một chuỗi Layer-1, nó hỗ trợ sẵn chuẩn hợp đồng an toàn bảo mật (XSC). Khi thực thi các hợp đồng thông minh mật, số tiền, vị thế và các bên tham gia sẽ không bị lộ trực tiếp trên trình duyệt dữ liệu của blockchain. Điều này là điều kiện cần thiết đối với người dùng tổ chức, nhưng xét trên mức độ hiển thị ra bên ngoài của toàn bộ hệ sinh thái thì lại là một thao tác ngược.

Điểm mâu thuẫn nằm ở đây: ngành crypto lâu nay xây dựng niềm tin dựa vào khái niệm “công khai có thể kiểm chứng”. Người dùng sẵn sàng đưa tài sản vào giao thức phần lớn là vì họ có thể tự tra cứu trên chuỗi để xác nhận rằng luồng tiền là ổn. Tuy nhiên lộ trình của Dusk lại đi theo hướng hoàn toàn ngược. Nó yêu cầu người dùng không phải “tin vào những thứ nhìn thấy được”, mà là “tin vào những thứ có thể chứng minh được”—bằng chứng không tri thức thay thế sổ cái công khai: người xác minh có thể xác nhận giao dịch là hợp lệ, nhưng quan sát bên ngoài không thể xem chi tiết. Việc chuyển đổi mô hình niềm tin này, đối với người dùng đã quen với dữ liệu on-chain công khai, thì ngưỡng chấp nhận thực sự không hề thấp.

Theo tôi, vấn đề mang tính thực tế hơn là: khi bên ngoài không thể thống kê trực tiếp hoạt động trên chuỗi, thì sự phát triển của hệ sinh thái sẽ được lượng hóa một cách khách quan như thế nào? Nếu ngay cả các chỉ số cơ bản trên chuỗi cũng phải được bọc bằng các chứng minh từ hợp đồng thông minh mật để suy ra gián tiếp, liệu ngưỡng phân tích có khiến tốc độ áp dụng của Dusk chậm lại không?

$DUSK cần chứng minh không chỉ là quyền riêng tư có thể làm được về mặt kỹ thuật, mà còn là sau khi cơ chế niềm tin được định nghĩa lại, liệu toàn bộ hệ sinh thái có còn tiếp tục thu hút những người dùng sẵn sàng “tin vào bằng chứng” chứ không phải “tin vào con số” hay không.

#dusk $DUSK @Dusk
Điểm hấp dẫn nhất của DeFi là tính “khả kết hợp”: đầu ra của một giao thức có thể được đưa trực tiếp vào giao thức tiếp theo, dòng tiền có thể ghép nối tự do như LEGO. Nhưng lợi thế này dựa trên một tiền đề—mọi trạng thái đều được công khai minh bạch, và mọi hợp đồng đều có thể đọc được số dư và vị thế của bất kỳ ai. Đây chính là chỗ khiến tôi bị kẹt khi đọc lại whitepaper của Dusk.

Dusk Network định vị mình như một blockchain lớp cơ sở (Layer-1) cho các ứng dụng tài chính với tính riêng tư. Là một chuỗi Layer-1, nó hỗ trợ nguyên sinh chuẩn hợp đồng an toàn bí mật (XSC), cho phép các hợp đồng thông minh bí mật được thực thi trong trạng thái được bảo mật. Vấn đề là: khi trạng thái của hợp đồng bị ẩn đi, thì các giao thức khác còn có thể tương tác với nó một cách an toàn hay không? Khả kết hợp dựa vào “khả năng đọc được”, còn quyền riêng tư dựa vào “không thể đọc được”—và hai điều này vốn dĩ xung đột ngay ở tầng kiến trúc.

Chuẩn XSC thực chất là cố gắng giải quyết lực căng này: thông qua bằng chứng không kiến thức (zero-knowledge proof), để các hợp đồng bên ngoài không cần nhìn thấy trạng thái đầy đủ, mà vẫn có thể xác minh một điều kiện nào đó có đúng hay không—ví dụ như liệu tài sản thế chấp có đủ không, hoặc tư cách có phù hợp không. Nói cách khác, tính khả kết hợp chuyển từ “chia sẻ dữ liệu” sang “chia sẻ bằng chứng”—đó là sự đổi hướng về mặt khái niệm, không chỉ đơn thuần là thêm một lớp mã hóa.

Nhưng tôi vẫn tò mò: mô hình ghép nối dựa trên bằng chứng như vậy khi liên kết xuyên qua nhiều giao thức sẽ có độ trễ và chi phí Gas có tăng lên đáng kể so với trạng thái công khai truyền thống không? Nếu mỗi lần tương tác đều phải tạo và xác minh thêm một lớp bằng chứng, thì tính thực dụng của hợp đồng thông minh bí mật trong các kịch bản tài chính phức tạp sẽ phụ thuộc rất nhiều vào việc liệu chi phí này có thể được hạ xuống hay không.

$DUSK bài kiểm tra thật sự không phải là có làm được quyền riêng tư hay không, mà là sau khi có quyền riêng tư rồi, cả hệ sinh thái có còn có thể tự do ghép nối như trước nữa không.

#dusk $DUSK @Dusk
Các tổ chức tài chính truyền thống muốn chuyển tài sản lên blockchain, rào cản lớn nhất rốt cuộc là gì? Không phải là ngưỡng kỹ thuật. Mà là việc: "khi đã đưa lên chuỗi, mọi đối tác giao dịch, số tiền và vị thế (phần nắm giữ) đều phải bị phơi bày dưới ánh sáng công khai"—điều này đối với các tổ chức căn bản là không thể chấp nhận. Đây cũng là lý do khi tôi xem lại whitepaper của Dusk, tôi đặc biệt chú ý đến chuẩn XSC (Confidential Security Contracts).

Dusk Network định vị mình là một blockchain riêng tư cho các ứng dụng tài chính. Với tư cách là một chuỗi Layer-1, họ không coi quyền riêng tư chỉ là một module cài thêm, mà trực tiếp hỗ trợ các smart contract bí mật ngay từ tầng giao thức. Điều này có nghĩa là logic của hợp đồng bản thân có thể xử lý thông tin nhạy cảm; số tiền giao dịch và danh tính các bên tham gia có thể được giữ bí mật. Đồng thời, trên chuỗi vẫn có thể xác minh tính hợp pháp của giao dịch.

Nhưng vấn đề đặt ra là: nếu không thể nhìn thấy nội dung giao dịch, thì cơ quan giám sát (regulatory) sẽ làm thế nào để thẩm định tuân thủ (compliance)? Đây thực chất là bài toán mang tính cấu trúc mà mọi blockchain riêng tư cấp tổ chức đều phải đối mặt. Cách tiếp cận của chuẩn XSC là dùng bằng chứng không kiến thức để tách rời khái niệm "xác minh" và "tiết lộ". Trạng thái hợp đồng có thể được giữ bí mật, nhưng việc thực thi hợp đồng có tuân thủ các quy tắc hay không vẫn có thể được chứng minh, mà không cần công khai chi tiết cho tất cả mọi người.

Tôi nghĩ giá trị của thiết kế này nằm ở chỗ: nó khiến "tuân thủ" và "quyền riêng tư" không còn là lựa chọn loại trừ lẫn nhau nữa, mà được tách thành hai lớp xử lý độc lập. Tuy nhiên, khi triển khai thực tế, các yêu cầu về nghĩa vụ tiết lộ ở các khu vực pháp lý (jurisdiction) khác nhau không giống nhau. Liệu chuẩn XSC có thể linh hoạt kết nối với khung quản lý của từng nơi hay không—có lẽ mới là chìa khóa quyết định liệu các tổ chức có thực sự sẵn sàng áp dụng hay không.

Cơ hội của $DUSK không nằm ở việc hô khẩu hiệu về quyền riêng tư, mà là ở chỗ: liệu có thể biến chuẩn smart contract bí mật này thành một hạ tầng mà tổ chức tài chính dám dùng và cơ quan giám sát có thể chấp nhận hay không.

#dusk
Vừa rồi đọc @Dusk bản “whitepaper”, khi thấy đoạn nói về chuẩn XSC (Confidential Security Contracts), tôi đã dừng lại và suy nghĩ rất lâu. Dusk Network định vị mình là một blockchain quyền riêng tư dành cho ứng dụng tài chính. Với tư cách là một chuỗi Layer-1, họ đưa các smart contract mật trực tiếp thành chuẩn gốc, thay vì chỉ gắn thêm một lớp quyền riêng tư lên các chain EVM sẵn có. Điểm chạm này khác với phần lớn các dự án.

Mâu thuẫn nằm ở đây: trong bối cảnh tài chính cần có quyền riêng tư, nhưng đồng thời cũng cần tính kiểm toán được (auditability). Hai yêu cầu này vốn dĩ xung khắc. Các public chain truyền thống công khai toàn bộ chi tiết giao dịch trên blockchain, bất kỳ ai cũng có thể tra cứu; điều đó căn bản không khả thi đối với việc phát hành tài sản ở mức độ tổ chức. Nhưng nếu hoàn toàn ẩn nội dung giao dịch, thì cơ quan giám sát sẽ dựa vào đâu để xác nhận tính tuân thủ? Chuẩn XSC chính là nhằm giải quyết bài toán khó này: thông qua zero-knowledge proofs để trạng thái hợp đồng được giữ bí mật, đồng thời vẫn giữ được tính xác minh—người thứ ba ngoài hai bên giao dịch không thể xem chi tiết, nhưng vẫn có thể chứng minh rằng giao dịch là hợp lệ.

Điều tôi thắc mắc nhất khi nghiên cứu phần này là: khi các confidential smart contract được triển khai ở quy mô lớn, liệu chi phí tính toán cho việc xác thực của các node có làm chậm ngược lại thông lượng toàn chuỗi không? Bởi vì việc tạo và xác minh zero-knowledge proofs vốn không hề rẻ. Nếu các tổ chức tài chính thật sự đưa việc phát hành các tài sản quy mô lớn lên Dusk, thì hệ thống dưới tải cao có thể chịu được không—đó mới là mấu chốt để chuẩn XSC có thể hiện thực trong bối cảnh tài chính.

$DUSK muốn giải quyết không phải “có nên có quyền riêng tư hay không”, mà là “quyền riêng tư và tuân thủ pháp lý có thể cùng tồn tại hay không”. Tôi thấy định hướng này thực tế hơn nhiều so với việc chỉ kêu gọi phi tập trung.

Vất vả rồi, anh cả

#baby
Một giao thức tự xưng là trustless, self-custody, vậy tại sao trong hệ sinh thái thanh lý lại cần đến các nhà cung cấp dịch vụ "MEV capability"? Khi thấy chính tài liệu roadmap của Babylon viết câu đó, tôi đã khựng lại một chút.

Tìm hiểu thêm thì phát hiện, khi phía chính thức lập kế hoạch cho hệ sinh thái TBV, họ có nhắc rằng để giao thức thực sự phổ biến, cần có một nhóm hạ tầng và nhà cung cấp dịch vụ chuyên nghiệp tham gia, bao gồm custodians, digital banks, API providers, Bitcoin LSTs, và cả "liquidators with MEV capability". Nói cách khác, ở mảng thanh lý này, phía chính thức kỳ vọng phải dựa vào những người chơi chuyên nghiệp có năng lực liên quan đến MEV thì mới có thể vận hành hiệu quả.

Mâu thuẫn nằm ở chỗ này: trong bối cảnh DeFi truyền thống, MEV thường đối lập với những câu chuyện như "công bằng, không cần tin cậy", và thường gắn với front-running, chạy trước, những hành vi khiến người dùng thông thường chịu thiệt. TBV một mặt nhấn mạnh BTC tự lưu ký, không cần bất kỳ trung gian nào, xác minh on-chain công khai minh bạch; nhưng mặt khác, trong thiết kế hệ sinh thái thanh lý, thực chất lại phụ thuộc vào các tay chơi chuyên nghiệp có năng lực MEV để tranh tốc độ. Điều đó có nghĩa là hiệu quả thực thi thanh lý cuối cùng, ở một mức độ nào đó, vẫn nằm trong tay một số ít người tham gia có lợi thế kỹ thuật.

Tôi cho rằng trustless chỉ giải quyết lớp vấn đề niềm tin ở khâu lưu ký tài sản và xác minh rút tiền, chứ không có nghĩa toàn bộ mặt vận hành của hệ sinh thái cũng hoàn toàn công bằng. @BabylonLabs_io Việc đưa các tay chơi MEV vào phía thanh lý, ở một mức độ nào đó, là thừa nhận thực tế này. $BABY Khi hệ sinh thái tiến tới trưởng thành, thiết kế về tính công bằng của thị trường thanh lý sẽ là một điểm rất đáng tiếp tục theo dõi.

#baby
Nếu tôi muốn cùng một lượng BTC cho đồng thời hai giao thức DeFi khác nhau vay, một vault có làm được không? Ban đầu tôi cứ nghĩ là được, vì trong whitepaper họ luôn nói TBV là "programmable Bitcoin collateral".

Nhưng tra tài liệu mới biết thì đáp án là không. Nhóm dự án đã nói rõ trong Founders Call gần đây: một vault không thể đồng thời định tuyến tới nhiều giao thức DeFi; mỗi vault khi được tạo ra sẽ được ràng buộc duy nhất với một giao thức smart contract bên ngoài. Lý do cũng giải thích rất rõ: họ không muốn cùng một vault bị phơi bày đồng thời dưới nhiều ứng dụng, vì quy tắc thanh lý và giả định về mức độ tin cậy giữa các giao thức khác nhau. Nếu trộn chung thì rủi ro sẽ khó đánh giá và khó tách bạch.

Một mặt họ hô "programmable", ám chỉ BTC có thể được lắp ghép tự do như những khối Lego vào nhiều kịch bản DeFi; nhưng mặt khác trong thiết kế lại cố tình giới hạn mỗi vault chỉ được gắn với một giao thức. Điều đó đồng nghĩa là nếu người dùng muốn vừa tham gia cho vay vừa tham gia đúc stablecoin thì phải chia BTC thành nhiều phần và khóa từng phần vào các vault khác nhau, khiến vốn lại bị chia nhỏ hơn.

Tuy nhiên, nếu nhìn từ một góc độ khác thì đây không phải lỗi (bug), mà là thỏa hiệp bảo mật mà nhóm chủ động lựa chọn: sẵn sàng hy sinh một phần tính linh hoạt để không để rủi ro lan truyền qua lại giữa các giao thức. Tôi nghĩ đây mới là cách hiểu đúng về hệ sinh thái $BABY : programmable không có nghĩa là tổ hợp vô hạn, mà là lựa chọn trong phạm vi ranh giới an toàn. Quyết định @BabylonLabs_io trong ngắn hạn có thể làm hạn chế tính linh hoạt khi sử dụng, nhưng về dài hạn lại khiến TBV chống rủi ro tốt hơn.

#baby
Cũng là sản phẩm của chính Babylon, vậy tại sao BTC staking và TBV lại trông không giống nhau về thiết kế niềm tin? Đây là điều mình thắc mắc sau khi so sánh hai tài liệu này.

Trong giao thức BTC staking ban đầu của Babylon, vì ngôn ngữ script của Bitcoin không có sẵn tính năng covenant, nên về mặt thiết kế họ phải dựa vào một nhóm “covenant emulation committee” (ngưỡng đa chữ ký 6 trên 9) để cùng ký các giao dịch unbonding và slashing, nhằm đảm bảo rằng tài sản được xử lý theo đúng quy tắc của giao thức; staker không thể hoàn toàn né được ủy ban này và tự hành động riêng lẻ. Cơ chế này đã hoạt động được một thời gian, và cũng là một giải pháp thỏa hiệp mà Babylon tự thừa nhận dưới những hạn chế của script Bitcoin.

Mâu thuẫn nằm ở chỗ: trong khi đó, whitepaper TBV lại liên tục nhấn mạnh rằng việc redeem vault không cần bất kỳ ủy ban hay operator nào đứng ra ký thay—thay vào đó, họ trực tiếp dùng bằng chứng gian lận (fraud proof) của BitVM3 kết hợp với xác minh ZK để thay thế các vai trò đó. Cùng một nhóm, đối mặt với cùng một giới hạn kỹ thuật “Bitcoin script không có covenant”, nhưng một bên lại chọn dùng committee đa chữ ký để giải quyết, trong khi bên kia lại sử dụng một lộ trình mật mã hoàn toàn khác để vượt qua committee. Điều này có ý nghĩa gì? Liệu điều kiện của chính bối cảnh staking phức tạp hơn (liên quan đến quy tắc slashing) nên vẫn chưa thể bỏ committee, hay là phương án BitVM3 của TBV thật ra cũng có thể áp dụng cho staking, nhưng họ chưa chuyển sang (chưa migrate) ở giai đoạn này?

Mình cho rằng sự chênh lệch này phản ánh đúng giá trị thực của TBV: nó có thể không chỉ là giải pháp redeem của riêng TBV, mà là lộ trình mà Babylon muốn loại bỏ sự phụ thuộc vào đường đi kỹ thuật của committee bên staking trong tương lai. @BabylonLabs_io Nếu thực sự có thể áp dụng tư duy của BitVM3 vào giao thức staking, thì $BABY mô hình niềm tin của hệ sinh thái sẽ nhất quán hơn.

#baby
Nếu một két sắt cần được rút tiền (chuộc lại) và bên còn lại phải chủ động phối hợp ký tên, thì nếu bên đó bị mất liên lạc hoặc không phản hồi, khoản BTC này có bị kẹt vĩnh viễn bên trong không? Đây là câu hỏi đầu tiên nảy ra của tôi sau khi đọc đoạn giao dịch ký trước (pre-signed) trong bản whitepaper.

Whitepaper dùng ví dụ của Bob và Larry để giải thích đường đi nước rút (redeem path): cả hai bên ngay từ đầu đã ký sẵn một bộ giao dịch theo điều kiện (điều kiện hóa). Khi một điều kiện cụ thể (chẳng hạn như ngưỡng giá) được kích hoạt, thì bên tương ứng mới có thể thực hiện việc rút tiền. Thiết kế này thực sự giúp tránh rủi ro bên một phía tự ý thay đổi điều kiện, vì mọi khả năng đều đã được viết cứng ngay từ lúc tạo két sắt và đã được ký sẵn.

Nhưng vẫn có một mâu thuẫn: whitepaper liên tục nhấn mạnh TBV là "trustless self-custody"—không cần dựa vào bất kỳ bên thứ ba nào để bảo vệ an toàn tài sản. Thế nhưng cơ chế ký trước này, về bản chất, vẫn cần tiền đề "bên kia phải có mặt, bên kia phải phối hợp" để quy trình có thể hoàn tất suôn sẻ. Nếu Larry đóng vai trò là bên đối thủ cố ý trì hoãn hoặc trực tiếp biến mất, thì về mặt lý thuyết, phần BTC của Bob sẽ bị kẹt trước khi điều kiện được kích hoạt—trừ khi whitepaper đã thiết kế rõ ràng một cơ chế dự phòng như timeout hoặc refund, để đảm bảo rằng tiền không bị khóa vĩnh viễn.

Tôi nghĩ đây mới là điểm cần phân biệt rõ khi đánh giá độ an toàn của TBV: self-custody giải quyết vấn đề "không bị bên thứ ba chiếm đoạt" tài sản, nhưng không có nghĩa là "khi đối thủ biến mất thì bạn vẫn lấy lại được tiền". Đây là hai mức độ đảm bảo khác nhau. @BabylonLabs_io muốn người dùng thực sự yên tâm, thì chi tiết thiết kế cơ chế thoát (timeout) là chìa khóa quyết định hệ thống này có thể triển khai và vận hành được hay không. $BABY nếu hệ sinh thái muốn đi xa bền vững, thì mảnh ghép này không thể thiếu.

#baby
Bản bạch giấy định vị TBV như “programable Bitcoin collateral” (tài sản thế chấp Bitcoin có thể lập trình), nhấn mạnh rằng nó có thể linh hoạt tích hợp vào nhiều bối cảnh DeFi như cho vay, đúc stablecoin, v.v. Nghe có vẻ rất “linh hoạt”. Nhưng khi lật đến đoạn nói về cơ chế chuộc lại, tôi nhận thấy một thiết kế không mấy ăn khớp với hình ảnh “linh hoạt” đó.

Hiện tại việc chuộc lại của TBV theo mô hình “whole vault” (toàn bộ kho tiền). Tức là, khi khóa vào bao nhiêu BTC thì lúc mở khóa cũng phải chuộc lại cả gói cùng một lúc, không hỗ trợ chỉ chuộc riêng một phần. Nói cách khác, nếu tôi chỉ muốn lấy lại một phần nhỏ BTC để đáp ứng nhu cầu vốn ngắn hạn thì không thể trực tiếp cắt ra từ vault. Tôi phải chuộc lại toàn bộ vault, tất toán tất cả các vị thế vay mượn, rồi mới khóa lại một vault mới để tiếp tục sử dụng phần BTC còn lại.

Mâu thuẫn nằm ở đây: bản bạch giấy liên tục nhấn mạnh từ “programable”, ngụ ý rằng BTC có thể được lắp ghép linh hoạt như LEGO vào các bối cảnh DeFi khác nhau, nhưng phía chuộc lại lại là cơ chế “cứng” nhất—chế độ toàn bộ. Mọi thay đổi cục bộ đều phải trả chi phí tái xây dựng toàn bộ vault. Điều này thực ra khá không khớp với câu chuyện nhấn mạnh hiệu quả sử dụng vốn và khả năng vận dụng linh hoạt.

Tôi cho rằng đây chính là vấn đề trải nghiệm mà TBV cần phải giải quyết trước khi phổ cập: @BabylonLabs_io đã làm rất vững trong thiết kế an toàn, nhưng để hệ sinh thái $BABY thu hút được nhiều người dùng thực tế hơn, liệu cơ chế chuộc lại có thể cho phép rút một phần hay không sẽ trực tiếp quyết định liệu nó có thực sự “programmable” hay không.

#baby
Hãy tìm hiểu thêm một chút: thông thường, một cầu nối xuyên chuỗi kiểu BitVM muốn cho người dùng rút tiền thì thường phải dựa vào một nhóm operator. Những người này có nhiệm vụ ứng trước BTC cho người dùng, sau đó tiền sẽ được “chuộc lại” từ phía cầu. Vấn đề là khi Bob muốn rút tiền, anh ta cần ít nhất một operator sẵn sàng giúp ứng trước; còn khi Bob muốn gửi tiền, lại cần tất cả các operator phối hợp, tương đương với việc niềm tin bị chia nhỏ và đặt lên cả một nhóm bên thứ ba.

Trong whitepaper, bước đột phá trực tiếp nhất của TBV chính là loại bỏ hoàn toàn vai trò operator này. Về thiết kế, Bob và Larry (tức là hai bên đã được thỏa thuận trước) bản thân là những người duy nhất có thể chuộc lại BTC; không cần bất kỳ bên trung gian nào ứng trước hay thực hiện việc chuộc lại. Việc rút tiền do chính hai bên tự nắm giữ. Điều này thực sự giải quyết vấn đề niềm tin ở lớp operator.

Nhưng khi tôi đọc đến đoạn về thanh lý (liquidation), tôi phát hiện một chi tiết: whitepaper cũng tự thừa nhận rằng để thực thi thanh lý cần có bằng chứng được ký bởi một oracle về giá, và phần này “về thực chất” vẫn cần niềm tin vào oracle đó. Nghĩa là, điểm tin cậy liên quan đến operator đã bị gỡ bỏ, nhưng điểm tin cậy của liquidation oracle vẫn còn đó; whitepaper không né tránh điều này, mà chính họ tự chỉ ra.

Tôi nghĩ điều này lại khiến TBV trông có vẻ trung thực hơn: phi tập trung hóa vốn không phải là làm một phát ăn ngay, mà là lần lượt bóc tách từng giả định về niềm tin của từng vai trò. @BabylonLabs_io đã giải quyết phần operator; $BABY hệ sinh thái tiếp theo cần đối mặt, chính là cách xử lý mảnh ghép cuối cùng: liquidation oracle.

#baby
Ngôn ngữ lập trình Bitcoin Script của Bitcoin thực ra khá sơ khai, không thể trực tiếp chạy các tác vụ xác minh mật mã phức tạp—đó cũng là lý do từ trước đến nay nhiều người cho rằng BTC không thể thực sự tham gia DeFi. Hôm nay mình muốn phổ cập về cách TBV vượt qua giới hạn này.

Công cụ cốt lõi được dùng trong whitepaper là garbled circuit (mạch ẩn danh/đánh rối). Đây là một kỹ thuật rất cũ trong mật mã học: ý tưởng là chuyển một logic phép tính thành hàng loạt cổng điện được mã hóa, để hai bên có thể cùng tính ra một kết quả mà không phải tiết lộ dữ liệu đầu vào của từng bên. Kết quả chỉ cho thấy một bit đúng/sai; toàn bộ quá trình trung gian hoàn toàn không thể nhìn thấy. TBV ứng dụng kỹ thuật này vào chuỗi Bitcoin, để thay cho việc Bitcoin Script ban đầu không chạy được “xác minh bằng chứng trạng thái hợp đồng bên ngoài” — phép tính này được chuyển sang cách dùng garbled circuit: đưa rất nhiều phép tính sang chạy ngoài chuỗi (off-chain), còn trên chuỗi thì mạng lưới Bitcoin chỉ cần xác thực kết quả cuối cùng đó là “đúng/sai”.

Điểm tinh tế của thiết kế này nằm ở chỗ: nó không cần sửa đổi các quy tắc đồng thuận (consensus) của chính Bitcoin, cũng không cần hard fork mềm (soft fork), mà vẫn có thể giúp BTC gián tiếp có năng lực xác minh các logic phức tạp. Đây cũng là lý do TBV làm được tự giám sát/ tự quản lý (self-custody), thay vì giống như các cầu cross-chain truyền thống, phải giao BTC cho một thực thể tập trung nào đó cất giữ.

Mình nghĩ đây mới là điều khiến hệ sinh thái $BABY xứng đáng được nhìn nhận lại: không phải thêm một giải pháp “đóng gói” coin nữa, mà là giải quyết một cách thực sự vấn đề giới hạn của ngôn ngữ kịch bản (script) lớp nền của Bitcoin.@BabylonLabs_io đã đưa kỹ thuật garbled circuit vốn nằm im trong mật mã học từ lâu, quay trở lại và áp dụng đúng chỗ.

#baby
Bộ sách trắng mô tả việc nâng cao hiệu quả của TBV rất hấp dẫn: quy trình gửi tiền peg-in chỉ mất khoảng 3 giờ (xác nhận 6 lần trên khối Bitcoin) là có thể hoàn tất, và phí dịch vụ cũng tiết kiệm được gần gấp ba so với phương án BitVM2 trước đó. Nhìn vào hai con số này, ban đầu tôi tưởng rằng TBV đã giải quyết triệt để các vấn đề về hiệu quả cho toàn bộ quy trình nạp/rút vốn.

Nhưng đọc kỹ phần rút tiền (peg-out) thì mới thấy câu chuyện không đơn giản như vậy. Việc gửi có thể nhanh đến vậy là vì chỉ cần xác nhận giao dịch gốc trên chuỗi Bitcoin; còn rút tiền phải đi theo cơ chế chứng minh gian lận của BitVM3, và trên chuỗi bắt buộc phải để lại một khoảng thời gian thử thách (challenge period) để người giám sát có thời gian xác minh, chất vấn rằng giao dịch rút đó có đúng với trạng thái hợp đồng tương ứng hay không—trong khoảng thời gian này, số tiền cũng chưa thể lập tức nhận được. Nói cách khác, “nâng cao hiệu quả” mà bộ sách trắng nhấn mạnh chủ yếu diễn ra ở phía gửi; còn phía rút, tốc độ cuối cùng vẫn bị ràng buộc bởi cơ chế an toàn, nên không thể nén xuống vô hạn.

Mâu thuẫn nằm ở chỗ: TBV vừa dùng “nhanh hơn, rẻ hơn” làm điểm bán để thu hút người dùng tham gia, vừa lại phải dựa vào khoảng thời gian thử thách để kéo dài quy trình rút nhằm đổi lấy tính an toàn—hai mục tiêu này về bản chất là kéo giật lẫn nhau, không phải cùng một bộ cơ chế có thể đồng thời làm tốt nhất.

Tôi cho rằng “cuộc chiến” mà hệ sinh thái $BABY trong tương lai cần đánh, chính là làm sao—mà vẫn không nới lỏng các giả định về an toàn—rút ngắn hơn nữa thời gian chờ ở phía rút. @BabylonLabs_io hiện tại thiết kế phần trải nghiệm gửi rất ấn tượng, nhưng sự cân bằng giữa hiệu quả ở phía rút và mức độ an toàn, mới là chìa khóa để TBV có thể thực sự phổ cập.

#baby $BABY
Mình xin giải thích nhanh cho mọi người: hiện nay rất nhiều giải pháp cho vay thế chấp BTC ở lớp nền đều dựa trên DLC (Discreet Log Contract). Nói đơn giản, đây là cách để tài sản bitcoin có thể tự động phân bổ quyền sở hữu theo kết quả của các sự kiện bên ngoài. Nghe có vẻ rất phi tập trung, nhưng khi triển khai thực tế, phần lớn các giao thức cho vay DLC vẫn cần một “ủy ban” — đóng vai trò đại diện cho bên cho vay để giám sát điều kiện, ký thay và thực hiện các giao dịch thanh toán, nhằm đảm bảo rằng khi điều kiện được kích hoạt thì tiền sẽ được chuyển về đúng nơi.

Mâu thuẫn nằm ở đây: mục tiêu ban đầu của thiết kế DLC là để BTC có thể tham gia hợp đồng điều kiện mà không cần dựa vào bất kỳ trung gian nào. Nhưng thực tế vận hành lại không thể tránh khỏi vai trò “ủy ban đại diện lợi ích của một bên”. Như vậy vấn đề tín nhiệm lại quay về điểm xuất phát, chỉ là đổi tên thành “ủy ban” mà thôi.

Cách TBV xử lý ở điểm này lại khác. Nó không để “ủy ban” thay ai đó quyết định, mà khóa BTC vào vault. Kết hợp cơ chế bằng chứng gian lận của BitVM3 và các bằng chứng ZK để xác minh trạng thái của hợp đồng bên ngoài tại thời điểm đó. Điều kiện rút tiền được “đóng đinh” trực tiếp trong kịch bản (script) trên chuỗi, không cần bất kỳ bên thứ ba đại diện cho lợi ích của ai để ký và cấp quyền.

Theo mình, đây mới là vấn đề cũ mà TBV thực sự đang giải quyết: đẩy “hợp đồng bitcoin theo điều kiện” đi xa hơn theo hướng phi tín nhiệm thực sự, thay vì vẫn dựa vào mô hình ủy ban đại diện. @BabylonLabs_io triển khai trong hệ sinh thái $BABY , thực chất là để bù đắp khoảng trống tín nhiệm mà mô hình cho vay DLC vẫn chưa giải quyết sạch sẽ.

#baby
Trong sách trắng có đưa ra một ví dụ: Bob và Larry đã ký trước một bộ giao dịch Bitcoin, điều kiện được ghi sẵn là nếu giá BTC giảm xuống dưới 50.000 USD thì Larry có thể đơn phương đóng vị thế. Tôi đọc đoạn này mà không nhịn được thắc mắc: mức giá 50.000 USD đó rốt cuộc là ai, và bằng cách nào, đã chứng minh cho mạng Bitcoin thấy?

Thiết kế cốt lõi của TBV là vault chỉ chấp nhận các bằng chứng ZK về trạng thái của hợp đồng thông minh bên ngoài, chứ không chấp nhận bất kỳ con số nào do một bên đơn phương tuyên bố. Về mặt lý thuyết, cơ chế này giải quyết vấn đề niềm tin “ai có quyền quyết định”, vì trước khi rút tiền thì phải xác minh rằng bằng chứng ZK đó có thật sự tương ứng với trạng thái hiện tại của hợp đồng trên chuỗi bên ngoài hay không. Nhưng ở đây có một lỗ hổng kỹ thuật dễ bị bỏ qua: bằng chứng ZK có thể đảm bảo rằng “hợp đồng bên ngoài thực sự đang ở một trạng thái nào đó”, nhưng lại không thể đảm bảo rằng “dữ liệu đầu vào của trạng thái đó là đúng”. Nói cách khác, nếu dữ liệu giá trên chuỗi bên ngoài vốn đã bị thao túng bởi kết quả oracle, thì việc xác minh ZK của TBV vẫn sẽ cho phép rút, bởi vì nó chỉ xác minh tính đúng đắn về mặt logic, chứ không xác minh độ chân thực của dữ liệu.

Nói ngắn gọn, TBV đã lấp đầy khoảng trống niềm tin “hãy tin bên trung gian (bridge)”, nhưng không và cũng không có ý định giải quyết rủi ro oracle của chính hợp đồng bên ngoài—thực ra đây là hai vấn đề khác nhau.

Tôi cho rằng đây mới là điểm cần phải phân biệt khi đánh giá độ an toàn của TBV: @BabylonLabs_io giải quyết vấn đề tự quản và xác minh ở phía Bitcoin, còn $BABY là hệ sinh thái khi kết nối vào các giao thức DeFi ở phía đó—tính an toàn của oracle của chính bên đó vẫn phải được tự mình kiểm soát, và hai vấn đề này không thể trộn lẫn với nhau.

#baby $BABY
Hôm nay muốn bàn về một điều khá “tầng đáy”: độ an toàn của TBV được xây dựng dựa trên những giả định nào.

Mình lật thử whitepaper thì thấy việc xác thực rút tiền của TBV dùng cơ chế “chứng minh gian lận” của BitVM3. Giả định cốt lõi là “1-of-N honest” (chỉ cần trong số nhiều người giám sát có ít nhất một người là trung thực, sẵn sàng trong thời gian diễn ra giai đoạn thách thức đưa ra sự nghi vấn), thì hệ thống có thể bắt được giao dịch rút tiền giả mạo. Mô hình này khá giống optimistic rollup: ưu điểm là lượng tính toán trên chuỗi nhỏ; dùng garbled circuits để chuyển phần lớn việc xác minh ra khỏi chuỗi, còn trên mạng Bitcoin chỉ cần xác minh bằng chứng nén cho giao dịch cuối cùng.

Nhưng ở đây có một lỗ hổng kỹ thuật dễ bị bỏ qua: rốt cuộc giả định an toàn này vẫn dựa trên tiền đề “có người đang theo dõi”. Trong giai đoạn thách thức, nếu không bên nào chủ động giám sát và nộp chứng minh gian lận thì về mặt lý thuyết, việc rút tiền độc hại vẫn có thể được thông qua. Nói cách khác, TBV chuyển vấn đề niềm tin từ chỗ “tin bên trung gian/bridge” sang chỗ “tin rằng ít nhất có một watchtower đang hoạt động trực tuyến”. Điều này không loại bỏ hoàn toàn niềm tin, mà chỉ phân phối lại niềm tin sang một vai trò khác mà cơ chế khuyến khích kinh tế rõ ràng hơn.

Mình nghĩ đây chính là phần mà hệ sinh thái $BABY sắp tới cần chứng minh: có thể xây dựng một cơ chế để watchtower có đủ động lực kinh tế duy trì việc giám sát online lâu dài hay không. Điều đó quyết định mức độ “trustless” mà TBV tuyên bố rốt cuộc vững đến đâu. @BabylonLabs_io nước đi này là rất thông minh, nhưng các chi tiết trong thiết kế cơ chế mới là thứ quyết định thật sự đến tính an toàn.