Binance Square
Liam_Carter
731 Bài đăng

Liam_Carter

Giao dịch mở
Trader thường xuyên
9 tháng
200 Đang theo dõi
6.8K+ Người theo dõi
1.2K+ Đã thích
Bài đăng
Danh mục đầu tư
·
--
Nhìn biểu đồ nến, tôi thấy Bitcoin đang dần trượt xuống từ đỉnh gần đây—nhưng nỗi hoảng loạn thường thấy lại không xuất hiện. Thị trường gấu có cách riêng để lộ ra ai thực sự cam kết khi thanh khoản dễ dãi biến mất. Gần đây, các cuộc trò chuyện xoay quanh BTCFi lại sôi động lên. Điều đó không có vẻ ngẫu nhiên; dòng vốn đang chủ động tìm những cách an toàn hơn để tạo lợi suất. Một hướng tôi đã xem xét kỹ là cách tiếp cận từ Babylon Labs. Họ xây dựng một thứ gọi là TBV: Bitcoin được khóa trực tiếp trong các script Taproot trên mạng chính Bitcoin. Không có cầu nối, không token bọc (wrapped). Sau đó, các bằng chứng mật mã cho phép bạn vay stablecoin từ Aave v4. Mỗi UTXO vẫn độc lập, nên bản thân dự án không thể di chuyển các coin. Mức độ “giữ hộ” bản địa như vậy mang lại sự yên tâm thật sự. Tuy vậy, tôi vẫn tự hỏi liệu việc lưu ký on-chain nghiêm ngặt như thế có thể hạn chế mức độ linh hoạt mà dòng vốn có thể di chuyển và được đem đi đầu tư hay không. Tiếp theo, tôi tìm hiểu Hashi trên Sui. Mô hình của họ gần như là ngược lại. Validator MPC kết hợp với Guardian multisig nắm giữ BTC, tạo ra hBTC (mint), và cho phép nó di chuyển tự do trong hệ sinh thái Sui. Các tổ chức có lẽ sẽ thích hiệu năng và phạm vi nhiều hơn các trường hợp sử dụng. Điều khiến tôi còn băn khoăn là liệu multisig cộng với MPC có thể loại bỏ hoàn toàn rủi ro tập trung hay không. Tôi không phải chuyên gia kỹ thuật sâu, nhưng các giả định tin cậy phức tạp hơn thường đồng nghĩa với nhiều điểm hỏng hóc tiềm ẩn hơn. Vì vậy, trước mắt chúng ta có hai hướng đi rõ ràng: một hướng ưu tiên lưu ký bản địa thuần túy, hướng còn lại ưu tiên tính tương thích (composability) và sự linh hoạt. Tôi bắt đầu nghĩ rằng sẽ không có một câu trả lời đúng duy nhất—có lẽ thiết kế chiến thắng sẽ pha trộn các yếu tố của cả hai. Câu hỏi quan trọng hơn cả biến động giá hằng ngày là: khi một đợt “thử lửa” thực sự cho thị trường gấu xuất hiện, hệ thống nào sẽ lộ ra vết nứt trước? TBV với các bằng chứng mật mã thuần túy liệu có bền vững hơn, hay các cơ chế kiểm soát rủi ro chuẩn cấp tổ chức của Hashi sẽ đứng vững tốt hơn? Câu trả lời đó có thể còn quan trọng hơn cả cây nến tiếp theo trên biểu đồ. @babylonlabs_io #baby $BABY
Nhìn biểu đồ nến, tôi thấy Bitcoin đang dần trượt xuống từ đỉnh gần đây—nhưng nỗi hoảng loạn thường thấy lại không xuất hiện. Thị trường gấu có cách riêng để lộ ra ai thực sự cam kết khi thanh khoản dễ dãi biến mất. Gần đây, các cuộc trò chuyện xoay quanh BTCFi lại sôi động lên. Điều đó không có vẻ ngẫu nhiên; dòng vốn đang chủ động tìm những cách an toàn hơn để tạo lợi suất.
Một hướng tôi đã xem xét kỹ là cách tiếp cận từ Babylon Labs. Họ xây dựng một thứ gọi là TBV: Bitcoin được khóa trực tiếp trong các script Taproot trên mạng chính Bitcoin. Không có cầu nối, không token bọc (wrapped). Sau đó, các bằng chứng mật mã cho phép bạn vay stablecoin từ Aave v4. Mỗi UTXO vẫn độc lập, nên bản thân dự án không thể di chuyển các coin. Mức độ “giữ hộ” bản địa như vậy mang lại sự yên tâm thật sự. Tuy vậy, tôi vẫn tự hỏi liệu việc lưu ký on-chain nghiêm ngặt như thế có thể hạn chế mức độ linh hoạt mà dòng vốn có thể di chuyển và được đem đi đầu tư hay không.
Tiếp theo, tôi tìm hiểu Hashi trên Sui. Mô hình của họ gần như là ngược lại. Validator MPC kết hợp với Guardian multisig nắm giữ BTC, tạo ra hBTC (mint), và cho phép nó di chuyển tự do trong hệ sinh thái Sui. Các tổ chức có lẽ sẽ thích hiệu năng và phạm vi nhiều hơn các trường hợp sử dụng. Điều khiến tôi còn băn khoăn là liệu multisig cộng với MPC có thể loại bỏ hoàn toàn rủi ro tập trung hay không. Tôi không phải chuyên gia kỹ thuật sâu, nhưng các giả định tin cậy phức tạp hơn thường đồng nghĩa với nhiều điểm hỏng hóc tiềm ẩn hơn.
Vì vậy, trước mắt chúng ta có hai hướng đi rõ ràng: một hướng ưu tiên lưu ký bản địa thuần túy, hướng còn lại ưu tiên tính tương thích (composability) và sự linh hoạt. Tôi bắt đầu nghĩ rằng sẽ không có một câu trả lời đúng duy nhất—có lẽ thiết kế chiến thắng sẽ pha trộn các yếu tố của cả hai. Câu hỏi quan trọng hơn cả biến động giá hằng ngày là: khi một đợt “thử lửa” thực sự cho thị trường gấu xuất hiện, hệ thống nào sẽ lộ ra vết nứt trước? TBV với các bằng chứng mật mã thuần túy liệu có bền vững hơn, hay các cơ chế kiểm soát rủi ro chuẩn cấp tổ chức của Hashi sẽ đứng vững tốt hơn? Câu trả lời đó có thể còn quan trọng hơn cả cây nến tiếp theo trên biểu đồ.
@BabylonLabs_io #baby $BABY
Đã xác minh
Khi testnet TBV của Babylon Labs chính thức đi vào hoạt động, có một chi tiết cứ liên tục được nhắc đến: một giao dịch Bitcoin duy nhất có thể mang tối đa 10 đầu ra HTLC. Thoạt nhìn, điều này nghe có vẻ như một mẹo tiết kiệm phí đơn giản. Nhưng cách nhìn đó đã bỏ lỡ điểm mấu chốt. Việc này không phải là gom 10 người dùng BTC vào một “quỹ” dùng chung. Mỗi đầu ra vẫn thuộc về một Vault riêng lẻ, được hỗ trợ bởi UTXO riêng của nó, cấu trúc giao dịch đã được ký trước riêng của nó, và tuyến rút riêng của nó. Mười đầu ra HTLC không phải là một “kho an toàn” tập thể—chúng là mười chiếc két độc lập được đặt trong cùng một thùng hàng. Việc vận chuyển hiệu quả hơn, nhưng mô hình bảo mật vẫn tách bạch. Ý tưởng cốt lõi là: có thể gộp hiệu quả, nhưng không thể gộp rủi ro. Mặc dù việc gom lô giảm chi phí, nó không làm giảm gánh nặng vận hành. Trong quá trình thiết lập, nhà cung cấp Vault vẫn phải thu thập chữ ký từ tất cả người tham gia và gửi lô đó lên Ethereum. Nếu VP ngoại tuyến, người dùng vẫn có thể khôi phục các chữ ký cần thiết từ chuỗi để hoàn tất PegIn. Và nếu VP không hợp tác trong giai đoạn hoàn trả (redeem), người dùng vẫn phải dựa vào khóa WOTS của chính họ và dữ liệu claim để tự giành quyền kiểm soát. Vì vậy, gom lô chỉ nén phí, không nén luồng quy trình bảo mật. Một phép so sánh tốt hơn là: nhiều hợp đồng bảo hiểm được đóng gói trong một kiện hàng. Việc giao hàng trở nên rẻ hơn, nhưng việc thẩm định, ký kết và yêu cầu bồi thường cho từng hợp đồng vẫn hoàn toàn tách biệt. Một gói gộp không có nghĩa là chia sẻ phạm vi bảo hiểm. Đó là lý do sau khi Babylon ra mắt mainnet, tôi quan tâm ít hơn đến việc đã tiết kiệm được bao nhiêu phí và quan tâm nhiều hơn đến ba tín hiệu thực sự: kích thước lô được phân bổ như thế nào, tần suất hoàn tất chữ ký từ đầu đến cuối ra sao, và người dùng có thể tự khôi phục nhanh đến mức nào khi VP không sẵn dùng. Những con số đó mới cho thấy thiết kế “được gom lô chứ không được gộp pool” này có thực sự xứng đáng hay không. Công nghệ có thể tối ưu chi phí. Còn bảo mật thì không chấp nhận giảm giá theo nhóm. @babylonlabs_io #baby $BABY
Khi testnet TBV của Babylon Labs chính thức đi vào hoạt động, có một chi tiết cứ liên tục được nhắc đến: một giao dịch Bitcoin duy nhất có thể mang tối đa 10 đầu ra HTLC.

Thoạt nhìn, điều này nghe có vẻ như một mẹo tiết kiệm phí đơn giản. Nhưng cách nhìn đó đã bỏ lỡ điểm mấu chốt.

Việc này không phải là gom 10 người dùng BTC vào một “quỹ” dùng chung. Mỗi đầu ra vẫn thuộc về một Vault riêng lẻ, được hỗ trợ bởi UTXO riêng của nó, cấu trúc giao dịch đã được ký trước riêng của nó, và tuyến rút riêng của nó. Mười đầu ra HTLC không phải là một “kho an toàn” tập thể—chúng là mười chiếc két độc lập được đặt trong cùng một thùng hàng. Việc vận chuyển hiệu quả hơn, nhưng mô hình bảo mật vẫn tách bạch.

Ý tưởng cốt lõi là: có thể gộp hiệu quả, nhưng không thể gộp rủi ro.

Mặc dù việc gom lô giảm chi phí, nó không làm giảm gánh nặng vận hành. Trong quá trình thiết lập, nhà cung cấp Vault vẫn phải thu thập chữ ký từ tất cả người tham gia và gửi lô đó lên Ethereum. Nếu VP ngoại tuyến, người dùng vẫn có thể khôi phục các chữ ký cần thiết từ chuỗi để hoàn tất PegIn. Và nếu VP không hợp tác trong giai đoạn hoàn trả (redeem), người dùng vẫn phải dựa vào khóa WOTS của chính họ và dữ liệu claim để tự giành quyền kiểm soát.

Vì vậy, gom lô chỉ nén phí, không nén luồng quy trình bảo mật.

Một phép so sánh tốt hơn là: nhiều hợp đồng bảo hiểm được đóng gói trong một kiện hàng. Việc giao hàng trở nên rẻ hơn, nhưng việc thẩm định, ký kết và yêu cầu bồi thường cho từng hợp đồng vẫn hoàn toàn tách biệt. Một gói gộp không có nghĩa là chia sẻ phạm vi bảo hiểm.

Đó là lý do sau khi Babylon ra mắt mainnet, tôi quan tâm ít hơn đến việc đã tiết kiệm được bao nhiêu phí và quan tâm nhiều hơn đến ba tín hiệu thực sự: kích thước lô được phân bổ như thế nào, tần suất hoàn tất chữ ký từ đầu đến cuối ra sao, và người dùng có thể tự khôi phục nhanh đến mức nào khi VP không sẵn dùng. Những con số đó mới cho thấy thiết kế “được gom lô chứ không được gộp pool” này có thực sự xứng đáng hay không.

Công nghệ có thể tối ưu chi phí. Còn bảo mật thì không chấp nhận giảm giá theo nhóm.
@BabylonLabs_io #baby $BABY
#baby $BABY @babylonlabs_io Hôm nay, tôi đã trò chuyện với bạn bè về @BabylonLabs_io, và có một điểm cứ khiến tôi bận tâm: không phải “kho quỹ” nào cũng giống nhau. Một vault DeFi điển hình về cơ bản là một pool dùng chung. Nhiều người dùng gửi vào một hợp đồng, và cả lợi nhuận lẫn rủi ro được phân bổ trong cùng một “giỏ”. Mô hình kho quỹ của TBV lại khác. Mỗi kho quỹ là một UTXO độc lập của riêng nó, với một tập hợp các đường rút tiền đã được ký trước (pre-signed) được xác định sẵn. Các kho quỹ không nhập lại vào một pool chung và cũng không trộn lẫn với nhau. Cấu trúc này giống một hộp ký gửi (safe-deposit box) riêng lẻ hơn là một quỹ cộng đồng. Một khác biệt quan trọng nữa: chính hợp đồng của giao thức không thể chuyển BTC ra khỏi script. Nó không thể đem cho vay, không thể tái sử dụng, cũng không thể chuyển hướng BTC sang nơi khác. Điều đó đồng nghĩa với việc các tài sản không thể được tái thế chấp (re-staked). Ở nhiều sản phẩm kiểu “gửi vào và kiếm lãi”, bạn phải tin nền tảng sẽ không dùng tiền của bạn cho các mục đích khác. Với TBV, giới hạn này được thực thi ngay ở cấp độ script. Đây không chỉ là một lời hứa; nó được thiết kế sẵn trong kiến trúc. Với các khoản lớn hơn, cá nhân tôi thích mô hình độc lập này hơn pool dùng chung. Nó giúp việc hiểu rõ mức giảm giá trị tối đa (maximum downside) trở nên dễ dàng hơn. Tuy nhiên, tôi vẫn chưa thấy các chi tiết script Taproot được công khai hay các báo cáo audit cho từng kho quỹ riêng lẻ, nên phần đó vẫn chưa rõ ràng. Trước khi gửi tiền vào bất cứ thứ gì được gọi là “kho quỹ”, tôi nghĩ câu hỏi đầu tiên nên rất đơn giản: đó có phải là một cấu trúc độc lập, hay chỉ là một pool quỹ dùng chung nhưng được gắn nhãn khác?
#baby $BABY @BabylonLabs_io

Hôm nay, tôi đã trò chuyện với bạn bè về @BabylonLabs_io, và có một điểm cứ khiến tôi bận tâm: không phải “kho quỹ” nào cũng giống nhau.

Một vault DeFi điển hình về cơ bản là một pool dùng chung. Nhiều người dùng gửi vào một hợp đồng, và cả lợi nhuận lẫn rủi ro được phân bổ trong cùng một “giỏ”.

Mô hình kho quỹ của TBV lại khác. Mỗi kho quỹ là một UTXO độc lập của riêng nó, với một tập hợp các đường rút tiền đã được ký trước (pre-signed) được xác định sẵn. Các kho quỹ không nhập lại vào một pool chung và cũng không trộn lẫn với nhau. Cấu trúc này giống một hộp ký gửi (safe-deposit box) riêng lẻ hơn là một quỹ cộng đồng.

Một khác biệt quan trọng nữa: chính hợp đồng của giao thức không thể chuyển BTC ra khỏi script. Nó không thể đem cho vay, không thể tái sử dụng, cũng không thể chuyển hướng BTC sang nơi khác. Điều đó đồng nghĩa với việc các tài sản không thể được tái thế chấp (re-staked). Ở nhiều sản phẩm kiểu “gửi vào và kiếm lãi”, bạn phải tin nền tảng sẽ không dùng tiền của bạn cho các mục đích khác. Với TBV, giới hạn này được thực thi ngay ở cấp độ script. Đây không chỉ là một lời hứa; nó được thiết kế sẵn trong kiến trúc.

Với các khoản lớn hơn, cá nhân tôi thích mô hình độc lập này hơn pool dùng chung. Nó giúp việc hiểu rõ mức giảm giá trị tối đa (maximum downside) trở nên dễ dàng hơn. Tuy nhiên, tôi vẫn chưa thấy các chi tiết script Taproot được công khai hay các báo cáo audit cho từng kho quỹ riêng lẻ, nên phần đó vẫn chưa rõ ràng.

Trước khi gửi tiền vào bất cứ thứ gì được gọi là “kho quỹ”, tôi nghĩ câu hỏi đầu tiên nên rất đơn giản: đó có phải là một cấu trúc độc lập, hay chỉ là một pool quỹ dùng chung nhưng được gắn nhãn khác?
#baby $BABY Vừa bị một cảnh báo từ máy chủ hất tung khỏi giấc ngủ vì có vẻ liên quan đến một vụ nổ. Màn hình của tôi vẫn còn nửa mờ khi tôi mở cuộc trò chuyện nhóm và thấy ai đó đăng một bảng so sánh mô hình tin cậy TBV. Mười phút nhìn mà mắt không rời, đến lúc đó tôi mới thực sự tỉnh hẳn. @babylonlabs_io Trước đây tôi cứ nghĩ các cầu nối cross-chain về cơ bản chỉ có hai kiểu: tập trung hoặc phi tập trung. Chọn kiểu phi tập trung hơn thì gần như an toàn. Bảng đó đã dập tắt ý tưởng ấy. Dù là một thiết kế “phi tập trung” thế hệ mới như cầu BitVM thì vẫn buộc Bob phải phụ thuộc vào một ủy ban ký 1-trong-n, một tập các operator 1-trong-m, và ít nhất một người thách thức đang hoạt động, cùng phối hợp làm việc với nhau. Chỉ cần bẻ gãy bất kỳ mắt xích nào thì số tiền cũng có thể chỉ “ngồi đó” bị kẹt. Các vault Bitcoin không cần niềm tin (trustless) lại là một câu chuyện khác. Ngay từ khoảnh khắc vault được tạo ra, nó đã được đồng ký bởi Bob và Larry. Hoàn toàn không có vai trò bên thứ ba nào cả. Việc rút tiền không cần phải tin tưởng bất kỳ ai. Ba vai trò đó—operator, ủy ban ký, và người thách thức—không phải là những thứ bị “loại bỏ tối ưu” khỏi thiết kế. Ngay từ đầu chúng vốn không được dự định tồn tại. Sự khác biệt còn trở nên rõ hơn khi xét đến cho vay. Với một thiết lập DLC, Larry chỉ cần từ chối đưa cho Bob bí mật hoàn trả và làm Bob không thể redeem—bài toán “tùy chọn miễn phí” kinh điển. Với TBV, điều kiện redeem là các chứng minh mật mã thuần túy. Không ai cần phải “cấp quyền.” Cá nhân tôi hiện vẫn chỉ chạy các khoản testnet nhỏ. Vốn chính chưa hề di chuyển. Tôi cũng không tìm được tài liệu rõ ràng về chính xác ngưỡng k-trong-n multisig được đặt như thế nào. Dòng chính thức là “governance quyết định”, nhưng các chi tiết thực tế vẫn chưa được công khai. Vậy câu hỏi thật sự là: liệu bạn có sẵn sàng đánh đổi tính thanh khoản tức thời của một cây cầu để loại bỏ thêm một lớp niềm tin hay không?
#baby $BABY
Vừa bị một cảnh báo từ máy chủ hất tung khỏi giấc ngủ vì có vẻ liên quan đến một vụ nổ. Màn hình của tôi vẫn còn nửa mờ khi tôi mở cuộc trò chuyện nhóm và thấy ai đó đăng một bảng so sánh mô hình tin cậy TBV. Mười phút nhìn mà mắt không rời, đến lúc đó tôi mới thực sự tỉnh hẳn.
@BabylonLabs_io
Trước đây tôi cứ nghĩ các cầu nối cross-chain về cơ bản chỉ có hai kiểu: tập trung hoặc phi tập trung. Chọn kiểu phi tập trung hơn thì gần như an toàn. Bảng đó đã dập tắt ý tưởng ấy. Dù là một thiết kế “phi tập trung” thế hệ mới như cầu BitVM thì vẫn buộc Bob phải phụ thuộc vào một ủy ban ký 1-trong-n, một tập các operator 1-trong-m, và ít nhất một người thách thức đang hoạt động, cùng phối hợp làm việc với nhau. Chỉ cần bẻ gãy bất kỳ mắt xích nào thì số tiền cũng có thể chỉ “ngồi đó” bị kẹt.
Các vault Bitcoin không cần niềm tin (trustless) lại là một câu chuyện khác. Ngay từ khoảnh khắc vault được tạo ra, nó đã được đồng ký bởi Bob và Larry. Hoàn toàn không có vai trò bên thứ ba nào cả. Việc rút tiền không cần phải tin tưởng bất kỳ ai.
Ba vai trò đó—operator, ủy ban ký, và người thách thức—không phải là những thứ bị “loại bỏ tối ưu” khỏi thiết kế. Ngay từ đầu chúng vốn không được dự định tồn tại.
Sự khác biệt còn trở nên rõ hơn khi xét đến cho vay. Với một thiết lập DLC, Larry chỉ cần từ chối đưa cho Bob bí mật hoàn trả và làm Bob không thể redeem—bài toán “tùy chọn miễn phí” kinh điển. Với TBV, điều kiện redeem là các chứng minh mật mã thuần túy. Không ai cần phải “cấp quyền.”
Cá nhân tôi hiện vẫn chỉ chạy các khoản testnet nhỏ. Vốn chính chưa hề di chuyển. Tôi cũng không tìm được tài liệu rõ ràng về chính xác ngưỡng k-trong-n multisig được đặt như thế nào. Dòng chính thức là “governance quyết định”, nhưng các chi tiết thực tế vẫn chưa được công khai.
Vậy câu hỏi thật sự là: liệu bạn có sẵn sàng đánh đổi tính thanh khoản tức thời của một cây cầu để loại bỏ thêm một lớp niềm tin hay không?
Đúng một phần
Tôi đã dành nửa đêm để đọc kỹ tài liệu whitepaper của @BabylonLabs_io và đối chiếu lại các con số chi phí on-chain cho cả hai thiết lập BitVM2 và BitVM3. Càng đi sâu, tôi càng thấy có điều gì đó không khớp. Hầu hết mọi người coi “cầu Bitcoin” (Bitcoin bridge) và “kho Bitcoin” (Bitcoin vault) gần như là cùng một thứ, chỉ khác nhau về các giả định an ninh. Tuy nhiên, khi bạn đào vào chi tiết, chúng thực sự là hai thiết kế hoàn toàn khác nhau. Một bridge sẽ tạo ra (mint) BTC được bọc có thể thay thế, và bất kỳ ai cũng có thể chuộc (redeem), vì vậy nó phải dựa vào một đầy đủ bộ các operator, ủy ban ký (signer committees), người thách thức (challengers) và các thành phần khác để đảm bảo việc chuộc được duy trì khả thi về mặt thanh toán. Còn vault thì ngược lại: khóa số tiền ngay từ ngày đầu đến hai địa chỉ được định sẵn trước (hãy nghĩ đến bên vay và bên cho vay). Những vai trò bổ sung đó đơn giản là không cần thiết. Các con số còn làm sự khác biệt rõ ràng hơn. Ở cách tiếp cận ban đầu của BitVM2, chi phí on-chain đo được để xác minh một ZK proof duy nhất là hơn 15.000 USD. Với BitVM3, cùng vụ tranh chấp đó giảm xuống khoảng 93 USD, trong khi một khoản nạp hoặc rút bình thường, không tranh chấp có thể tốn ít nhất khoảng 2,66 USD. Chênh lệch này xấp xỉ 170 lần—không phải chỉnh một tham số, mà là thay đổi hoàn toàn cách tiếp cận. Thứ từng là “tiết lộ mọi thứ on-chain thông qua một bí mật” nay trở thành một cuộc đối đầu theo trò chơi (game-theoretic) diễn ra ngoài chuỗi bên trong một mạch tổng hợp (mixed circuit). Niềm tin on-chain thu nhỏ từ ba bên xuống còn hai. Hiện tại tôi đang chạy một vị thế testnet nhỏ chủ yếu để cảm nhận hành vi của cơ chế time-lock trên nhánh tranh chấp. Việc cho rằng lưu trữ ngoài chuỗi tốn khoảng 1 USD mỗi tháng chỉ đến từ các tài liệu chính thức; tôi chưa tìm được nguồn độc lập để xác nhận điều đó. Khi bạn kiểm tra chi phí on-chain trong thực tế hằng ngày, bạn chỉ nhìn vào các con số ở “đường đi suôn sẻ”, hay bạn cũng tính giá cho các kịch bản cực đoan?@babylonlabs_io #baby $BABY
Tôi đã dành nửa đêm để đọc kỹ tài liệu whitepaper của @BabylonLabs_io và đối chiếu lại các con số chi phí on-chain cho cả hai thiết lập BitVM2 và BitVM3. Càng đi sâu, tôi càng thấy có điều gì đó không khớp.
Hầu hết mọi người coi “cầu Bitcoin” (Bitcoin bridge) và “kho Bitcoin” (Bitcoin vault) gần như là cùng một thứ, chỉ khác nhau về các giả định an ninh. Tuy nhiên, khi bạn đào vào chi tiết, chúng thực sự là hai thiết kế hoàn toàn khác nhau. Một bridge sẽ tạo ra (mint) BTC được bọc có thể thay thế, và bất kỳ ai cũng có thể chuộc (redeem), vì vậy nó phải dựa vào một đầy đủ bộ các operator, ủy ban ký (signer committees), người thách thức (challengers) và các thành phần khác để đảm bảo việc chuộc được duy trì khả thi về mặt thanh toán. Còn vault thì ngược lại: khóa số tiền ngay từ ngày đầu đến hai địa chỉ được định sẵn trước (hãy nghĩ đến bên vay và bên cho vay). Những vai trò bổ sung đó đơn giản là không cần thiết.
Các con số còn làm sự khác biệt rõ ràng hơn. Ở cách tiếp cận ban đầu của BitVM2, chi phí on-chain đo được để xác minh một ZK proof duy nhất là hơn 15.000 USD. Với BitVM3, cùng vụ tranh chấp đó giảm xuống khoảng 93 USD, trong khi một khoản nạp hoặc rút bình thường, không tranh chấp có thể tốn ít nhất khoảng 2,66 USD. Chênh lệch này xấp xỉ 170 lần—không phải chỉnh một tham số, mà là thay đổi hoàn toàn cách tiếp cận. Thứ từng là “tiết lộ mọi thứ on-chain thông qua một bí mật” nay trở thành một cuộc đối đầu theo trò chơi (game-theoretic) diễn ra ngoài chuỗi bên trong một mạch tổng hợp (mixed circuit). Niềm tin on-chain thu nhỏ từ ba bên xuống còn hai.
Hiện tại tôi đang chạy một vị thế testnet nhỏ chủ yếu để cảm nhận hành vi của cơ chế time-lock trên nhánh tranh chấp. Việc cho rằng lưu trữ ngoài chuỗi tốn khoảng 1 USD mỗi tháng chỉ đến từ các tài liệu chính thức; tôi chưa tìm được nguồn độc lập để xác nhận điều đó.
Khi bạn kiểm tra chi phí on-chain trong thực tế hằng ngày, bạn chỉ nhìn vào các con số ở “đường đi suôn sẻ”, hay bạn cũng tính giá cho các kịch bản cực đoan?@BabylonLabs_io #baby $BABY
Đúng một phần
“Người dùng trực tiếp kiểm soát việc chuộc lại” nghe có vẻ yên tâm — cho đến khi phía bên kia đơn giản là từ chối không “chơi theo”. Tôi đã mắc kẹt ở một phần trong bản whitepaper TBV của @BabylonLabs_io, phần này khẳng định rằng “vault phi tín nhiệm loại bỏ hoàn toàn người vận hành.” Thiết kế cho phép hai bên đã được xác định trước có quyền trực tiếp đối với việc chuộc lại. Không cần một người vận hành trung gian. Điều này loại bỏ gọn gàng rủi ro kinh điển của bên thứ ba rút cạn tiền. Nó giải quyết vấn đề bị đánh cắp. Nhưng còn tính “liveness” (tính sẵn sàng/tiếp tục thực thi) thì sao? Bản whitepaper đối chiếu vault phi tín nhiệm với cầu BitVM. Trong mô hình BitVM, người vận hành phải chuyển tiếp (relay) giao dịch chuộc lại; nếu người vận hành đó trở nên độc hại, tiền có thể gặp rủi ro. Còn TBV thì cho phép hai đối tác tự nắm giữ các khóa chuộc lại. Mật mã đảm bảo rằng, miễn là các script được viết đúng, không bên nào có thể chiếm đoạt BTC không thuộc về mình. An toàn khá vững: không ai có thể cưỡng ép lấy thứ thuộc về người khác. Tuy nhiên, “an toàn” không đồng nghĩa với “liveness”. Nếu việc mở khóa tiền đòi hỏi đối tác phải ký hoặc hoàn tất một bước, và bên đó đi offline, biến mất hoặc chỉ đơn giản là từ chối hợp tác, thì các đồng có thể bị khóa vĩnh viễn. Bản whitepaper nhấn mạnh rằng “không ai có thể đánh cắp tiền của bạn,” nhưng lại không nói rõ ràng điều gì sẽ xảy ra khi bên kia thất bại trong việc hành động. Khả năng phòng chống bị đánh cắp không tự động bảo vệ được khỏi rủi ro tiền bị đóng băng. Thuật ngữ “phi tín nhiệm” thường khiến người ta chỉ tập trung vào các cam kết chống đánh cắp, trong khi bỏ qua rủi ro về thanh khoản và tính sẵn có — cả hai đều là một phần của “bảo mật tài sản thực”. Kết luận của tôi: TBV làm rất tốt trong việc ngăn chặn đánh cắp trắng trợn. Nhưng khi đánh giá bất kỳ thiết kế đối tác hai bên nào trong DeFi, phải đặt ra hai câu hỏi riêng: Tiền có thể bị đánh cắp không? Tiền có thể bị kẹt vĩnh viễn không? Đây là hai chiều rủi ro độc lập. Hiểu được sự tách bạch này là điều thiết yếu để nắm được mô hình bảo mật thực sự của $BABY — thay vì chỉ bị dẫn dắt bởi ý nghĩa bề mặt của “phi tín nhiệm”. #baby $BABY @babylonlabs_io
“Người dùng trực tiếp kiểm soát việc chuộc lại” nghe có vẻ yên tâm — cho đến khi phía bên kia đơn giản là từ chối không “chơi theo”.
Tôi đã mắc kẹt ở một phần trong bản whitepaper TBV của @BabylonLabs_io, phần này khẳng định rằng “vault phi tín nhiệm loại bỏ hoàn toàn người vận hành.” Thiết kế cho phép hai bên đã được xác định trước có quyền trực tiếp đối với việc chuộc lại. Không cần một người vận hành trung gian. Điều này loại bỏ gọn gàng rủi ro kinh điển của bên thứ ba rút cạn tiền.
Nó giải quyết vấn đề bị đánh cắp. Nhưng còn tính “liveness” (tính sẵn sàng/tiếp tục thực thi) thì sao?
Bản whitepaper đối chiếu vault phi tín nhiệm với cầu BitVM. Trong mô hình BitVM, người vận hành phải chuyển tiếp (relay) giao dịch chuộc lại; nếu người vận hành đó trở nên độc hại, tiền có thể gặp rủi ro. Còn TBV thì cho phép hai đối tác tự nắm giữ các khóa chuộc lại. Mật mã đảm bảo rằng, miễn là các script được viết đúng, không bên nào có thể chiếm đoạt BTC không thuộc về mình. An toàn khá vững: không ai có thể cưỡng ép lấy thứ thuộc về người khác.
Tuy nhiên, “an toàn” không đồng nghĩa với “liveness”. Nếu việc mở khóa tiền đòi hỏi đối tác phải ký hoặc hoàn tất một bước, và bên đó đi offline, biến mất hoặc chỉ đơn giản là từ chối hợp tác, thì các đồng có thể bị khóa vĩnh viễn. Bản whitepaper nhấn mạnh rằng “không ai có thể đánh cắp tiền của bạn,” nhưng lại không nói rõ ràng điều gì sẽ xảy ra khi bên kia thất bại trong việc hành động. Khả năng phòng chống bị đánh cắp không tự động bảo vệ được khỏi rủi ro tiền bị đóng băng.
Thuật ngữ “phi tín nhiệm” thường khiến người ta chỉ tập trung vào các cam kết chống đánh cắp, trong khi bỏ qua rủi ro về thanh khoản và tính sẵn có — cả hai đều là một phần của “bảo mật tài sản thực”.
Kết luận của tôi: TBV làm rất tốt trong việc ngăn chặn đánh cắp trắng trợn. Nhưng khi đánh giá bất kỳ thiết kế đối tác hai bên nào trong DeFi, phải đặt ra hai câu hỏi riêng:
Tiền có thể bị đánh cắp không?
Tiền có thể bị kẹt vĩnh viễn không?
Đây là hai chiều rủi ro độc lập. Hiểu được sự tách bạch này là điều thiết yếu để nắm được mô hình bảo mật thực sự của $BABY — thay vì chỉ bị dẫn dắt bởi ý nghĩa bề mặt của “phi tín nhiệm”.
#baby $BABY @BabylonLabs_io
Đã xác minh
#baby $BABY Hôm qua, khi đọc tài liệu của Babylon, tôi đã dừng lại ở trang “các giả định về an toàn”. Ai cũng đang hô vang “Làm cho Bitcoin-native đi vào DeFi”, nhưng một câu hỏi thực tế hơn lại ập đến với tôi: một khi BTC của bạn đã bị khóa trong một Taproot script, thì bạn thực sự phải làm gì để lấy lại nó? Việc unbonding không hề đơn giản. Bạn có thể chờ hết thời gian timelock đầy đủ khoảng ~64.000 block (khoảng 15 tháng), hoặc unbond chủ động—đòi hỏi Ủy ban Covenant phải ký xác nhận rồi sau đó phải trải qua một giai đoạn khóa lại thứ hai. EOTS nêu rõ: nếu một Finality Provider double-sign tại cùng độ cao đó, khóa bị rò rỉ và phần stake của bạn vẫn có thể bị slashing trong khung unbonding đó. Vì vậy, việc thoát ra là một “cửa sổ” theo thời gian, bị ràng buộc bởi quy tắc giao thức, chứ không phải chỉ cần unstake bất kỳ lúc nào. Thanh lý TBV cũng rất đáng chú ý. Bạn có thể vay dựa trên BTC mà không cần từ bỏ quyền giám sát/custody; mỗi Vault ánh xạ tới một UTXO độc lập của riêng nó. Trong một sự kiện thanh lý, bên thanh lý sẽ thanh toán ngay bằng WBTC, nhưng BTC gốc chỉ trở nên có thể đổi lấy (redeemable) sau khi cửa sổ “fraud-proof” kết thúc. Điều này tách dòng thời gian: nhà kinh doanh chênh lệch phải ứng trước WBTC trước, chịu rủi ro biến động giá và chi phí tài trợ. Tôi không tìm thấy câu trả lời rõ ràng rằng liệu việc sẵn sàng cung cấp thanh khoản ứng trước đó có khiến mọi thứ “sụp đổ” khi mức độ biến động tăng vọt hay không. Triết lý của Babylon giữ quyền kiểm soát tối hậu với chính Bitcoin. Lộ trình rất rõ ràng: Giai đoạn 1 tập trung vào phát triển xoay quanh Bitcoin, Giai đoạn 2 chuyển sang Cosmos, và Giai đoạn 3 mang staking đa tài sản. Nhưng người dùng cần tự nhận thức rằng slashing là có thật, và việc chấp nhận độ trễ khi thoát là một phần của sự đánh đổi; đó là một đường cong học tập khách quan. Khi bạn đánh giá các dự án, bạn có đào sâu đến mức này về cơ chế thoát và thanh lý không? Rất muốn nghe xem bạn có đi sâu đến vậy không—hãy để lại bình luận.@babylonlabs_io $LAB
#baby $BABY Hôm qua, khi đọc tài liệu của Babylon, tôi đã dừng lại ở trang “các giả định về an toàn”. Ai cũng đang hô vang “Làm cho Bitcoin-native đi vào DeFi”, nhưng một câu hỏi thực tế hơn lại ập đến với tôi: một khi BTC của bạn đã bị khóa trong một Taproot script, thì bạn thực sự phải làm gì để lấy lại nó?

Việc unbonding không hề đơn giản. Bạn có thể chờ hết thời gian timelock đầy đủ khoảng ~64.000 block (khoảng 15 tháng), hoặc unbond chủ động—đòi hỏi Ủy ban Covenant phải ký xác nhận rồi sau đó phải trải qua một giai đoạn khóa lại thứ hai. EOTS nêu rõ: nếu một Finality Provider double-sign tại cùng độ cao đó, khóa bị rò rỉ và phần stake của bạn vẫn có thể bị slashing trong khung unbonding đó. Vì vậy, việc thoát ra là một “cửa sổ” theo thời gian, bị ràng buộc bởi quy tắc giao thức, chứ không phải chỉ cần unstake bất kỳ lúc nào.

Thanh lý TBV cũng rất đáng chú ý. Bạn có thể vay dựa trên BTC mà không cần từ bỏ quyền giám sát/custody; mỗi Vault ánh xạ tới một UTXO độc lập của riêng nó. Trong một sự kiện thanh lý, bên thanh lý sẽ thanh toán ngay bằng WBTC, nhưng BTC gốc chỉ trở nên có thể đổi lấy (redeemable) sau khi cửa sổ “fraud-proof” kết thúc. Điều này tách dòng thời gian: nhà kinh doanh chênh lệch phải ứng trước WBTC trước, chịu rủi ro biến động giá và chi phí tài trợ. Tôi không tìm thấy câu trả lời rõ ràng rằng liệu việc sẵn sàng cung cấp thanh khoản ứng trước đó có khiến mọi thứ “sụp đổ” khi mức độ biến động tăng vọt hay không.

Triết lý của Babylon giữ quyền kiểm soát tối hậu với chính Bitcoin. Lộ trình rất rõ ràng: Giai đoạn 1 tập trung vào phát triển xoay quanh Bitcoin, Giai đoạn 2 chuyển sang Cosmos, và Giai đoạn 3 mang staking đa tài sản. Nhưng người dùng cần tự nhận thức rằng slashing là có thật, và việc chấp nhận độ trễ khi thoát là một phần của sự đánh đổi; đó là một đường cong học tập khách quan.

Khi bạn đánh giá các dự án, bạn có đào sâu đến mức này về cơ chế thoát và thanh lý không? Rất muốn nghe xem bạn có đi sâu đến vậy không—hãy để lại bình luận.@BabylonLabs_io
$LAB
#baby $BABY Tôi đã chứng kiến mọi chu kỳ thị trường đều tự bịa ra một lý do mới để đẩy Bitcoin vượt xa những gì nó được thiết kế để làm. Tôi đã đủ lâu để nhớ thời điểm mà gần như dự án nào cũng khẳng định rằng nó sẽ “mở khóa thanh khoản BTC”. Hầu hết đều đi theo cùng một khuôn mẫu: token được bọc, bên giám hộ được đặt niềm tin, các cầu nối lặng lẽ trở thành điểm lỗi duy nhất, và cộng đồng coi sự phức tạp không cần thiết là một bước tiến. Babylon nổi bật vì một lý do mà tôi không ngờ tới. Không phải vì nó mang lại lợi suất—crypto chưa bao giờ thiếu những lời hứa. Nó nổi bật vì bắt đầu từ một thực tế khó chịu: hàng nghìn tỷ USD Bitcoin phần lớn đang nằm yên, trong khi các chuỗi mới hơn lại phải mất nhiều năm để cố mượn uy tín của nó. Tôi vẫn chưa chắc liệu vấn đề đó có cần được giải quyết hay không. Có điều gì đó hơi kỳ lạ khi nhìn Bitcoin—một tài sản được xây dựng dựa trên sự kiềm chế có chủ đích—dần dần trở thành tài sản thế chấp cho hầu như mọi thứ khác. Việc đặt cược tự lưu ký có vẻ “sạch” hơn các mô hình trước đây. Không cần cầu nối, không phải từ bỏ khóa riêng, không chuyển đổi đồng coin sang những hình thức xa lạ. Tuy vậy, tôi đã thấy đủ nhiều hệ thống được gắn nhãn “không cần tin tưởng” để rồi dần dần tích lũy các giả định về niềm tin theo thời gian. Dù sao, cái này lại có cảm giác khác. Có lẽ vì Babylon không cố thuyết phục tôi rằng chính Bitcoin phải thay đổi. Nó giống như phần còn lại của thế giới crypto cuối cùng cũng thừa nhận rằng họ vẫn cần Bitcoin. Sau từng ấy năm, đây có lẽ là điều thành thật nhất mà thị trường này đã nói trong một thời gian rất dài.@babylonlabs_io 😀 {spot}(BABYUSDT)
#baby $BABY Tôi đã chứng kiến mọi chu kỳ thị trường đều tự bịa ra một lý do mới để đẩy Bitcoin vượt xa những gì nó được thiết kế để làm.
Tôi đã đủ lâu để nhớ thời điểm mà gần như dự án nào cũng khẳng định rằng nó sẽ “mở khóa thanh khoản BTC”. Hầu hết đều đi theo cùng một khuôn mẫu: token được bọc, bên giám hộ được đặt niềm tin, các cầu nối lặng lẽ trở thành điểm lỗi duy nhất, và cộng đồng coi sự phức tạp không cần thiết là một bước tiến.
Babylon nổi bật vì một lý do mà tôi không ngờ tới. Không phải vì nó mang lại lợi suất—crypto chưa bao giờ thiếu những lời hứa. Nó nổi bật vì bắt đầu từ một thực tế khó chịu: hàng nghìn tỷ USD Bitcoin phần lớn đang nằm yên, trong khi các chuỗi mới hơn lại phải mất nhiều năm để cố mượn uy tín của nó.
Tôi vẫn chưa chắc liệu vấn đề đó có cần được giải quyết hay không.
Có điều gì đó hơi kỳ lạ khi nhìn Bitcoin—một tài sản được xây dựng dựa trên sự kiềm chế có chủ đích—dần dần trở thành tài sản thế chấp cho hầu như mọi thứ khác. Việc đặt cược tự lưu ký có vẻ “sạch” hơn các mô hình trước đây. Không cần cầu nối, không phải từ bỏ khóa riêng, không chuyển đổi đồng coin sang những hình thức xa lạ. Tuy vậy, tôi đã thấy đủ nhiều hệ thống được gắn nhãn “không cần tin tưởng” để rồi dần dần tích lũy các giả định về niềm tin theo thời gian.
Dù sao, cái này lại có cảm giác khác.
Có lẽ vì Babylon không cố thuyết phục tôi rằng chính Bitcoin phải thay đổi. Nó giống như phần còn lại của thế giới crypto cuối cùng cũng thừa nhận rằng họ vẫn cần Bitcoin.
Sau từng ấy năm, đây có lẽ là điều thành thật nhất mà thị trường này đã nói trong một thời gian rất dài.@BabylonLabs_io 😀
#baby $BABY Vui lòng nhấn và giữ URL để sao chép, sau đó sử dụng trình duyệt để mở nếu bạn muốn xem nội dung đó.
#baby $BABY Vui lòng nhấn và giữ URL để sao chép, sau đó sử dụng trình duyệt để mở nếu bạn muốn xem nội dung đó.
Đúng một phần
#newt $NEWT @NewtonProtocol Chiều nay ở văn phòng, tôi đang đọc tài liệu kỹ thuật của Newton Protocol và có một phần thực sự thu hút sự chú ý của tôi: “đường ống song song TEE + ZKP.” Trên giấy tờ, nó trông thực sự rất thông minh. Ý tưởng cốt lõi khá hợp lý. TEE được thiết kế để xử lý nhanh việc thực thi ngoài chuỗi, còn ZKP biến kết quả thành một bằng chứng có thể được kiểm chứng trên chuỗi. Vì vậy thay vì yêu cầu mọi người chỉ tin vào phép tính, hệ thống cố gắng biến nó thành một thứ có thể được xác thực về mặt toán học. Phần này thật tinh tế, và tôi hiểu vì sao thiết kế lại được quan tâm. Tuy nhiên, khi nhìn vượt qua khái niệm và đi vào các giới hạn thực tiễn, một số lo ngại bắt đầu xuất hiện. Vấn đề lớn nhất là tạo bằng chứng. Bằng chứng ZKP không hề rẻ để tạo, và chỉ riêng điều đó thôi cũng có thể làm chậm hệ thống. HTX Research cũng ghi nhận rằng mô hình TEE + ZKP có thể gặp các nút thắt về hiệu năng và sự phụ thuộc vào phần cứng. Newton’s Prover Core hỗ trợ các zkVM như Risc0 và SP1, nhưng điều đó không xóa được thực tế rằng việc tạo bằng chứng vẫn rất tốn tài nguyên. Nếu có nhiều tác nhân chạy cùng lúc, tình trạng ùn tắc và độ trễ gần như là điều không thể tránh khỏi. Thế nhưng whitepaper lại không giải thích rõ ràng hệ thống dự định xử lý việc tạo bằng chứng song song ở quy mô lớn như thế nào. Ngoài ra còn có câu hỏi về phần cứng. TEEs phụ thuộc vào phần cứng enclave bảo mật, và công việc xác thực của validator thường cần máy móc mạnh. Điều này có nghĩa là mức rào cản không thực sự thấp. Theo thời gian, điều này có thể đẩy sự tham gia nhiều hơn về phía các tổ chức thay vì người dùng phổ thông. Gat cũng chỉ ra rằng ngăn xếp của giao thức khá phức tạp và việc triển khai ổn định vẫn đối mặt với các thách thức kỹ thuật thực sự. Vì vậy, kiến trúc đúng là tinh tế. Nhưng nếu phi tập trung phụ thuộc vào phần cứng đắt tiền và một nhóm nhỏ các nhà vận hành mạnh, thì nó thực sự phi tập trung đến mức nào trong thực tế? Chỉ là quan điểm cá nhân của tôi, không phải lời khuyên đầu tư. $LAB
#newt $NEWT @NewtonProtocol
Chiều nay ở văn phòng, tôi đang đọc tài liệu kỹ thuật của Newton Protocol và có một phần thực sự thu hút sự chú ý của tôi: “đường ống song song TEE + ZKP.” Trên giấy tờ, nó trông thực sự rất thông minh.

Ý tưởng cốt lõi khá hợp lý. TEE được thiết kế để xử lý nhanh việc thực thi ngoài chuỗi, còn ZKP biến kết quả thành một bằng chứng có thể được kiểm chứng trên chuỗi. Vì vậy thay vì yêu cầu mọi người chỉ tin vào phép tính, hệ thống cố gắng biến nó thành một thứ có thể được xác thực về mặt toán học. Phần này thật tinh tế, và tôi hiểu vì sao thiết kế lại được quan tâm.

Tuy nhiên, khi nhìn vượt qua khái niệm và đi vào các giới hạn thực tiễn, một số lo ngại bắt đầu xuất hiện.

Vấn đề lớn nhất là tạo bằng chứng. Bằng chứng ZKP không hề rẻ để tạo, và chỉ riêng điều đó thôi cũng có thể làm chậm hệ thống. HTX Research cũng ghi nhận rằng mô hình TEE + ZKP có thể gặp các nút thắt về hiệu năng và sự phụ thuộc vào phần cứng. Newton’s Prover Core hỗ trợ các zkVM như Risc0 và SP1, nhưng điều đó không xóa được thực tế rằng việc tạo bằng chứng vẫn rất tốn tài nguyên. Nếu có nhiều tác nhân chạy cùng lúc, tình trạng ùn tắc và độ trễ gần như là điều không thể tránh khỏi. Thế nhưng whitepaper lại không giải thích rõ ràng hệ thống dự định xử lý việc tạo bằng chứng song song ở quy mô lớn như thế nào.

Ngoài ra còn có câu hỏi về phần cứng. TEEs phụ thuộc vào phần cứng enclave bảo mật, và công việc xác thực của validator thường cần máy móc mạnh. Điều này có nghĩa là mức rào cản không thực sự thấp. Theo thời gian, điều này có thể đẩy sự tham gia nhiều hơn về phía các tổ chức thay vì người dùng phổ thông. Gat cũng chỉ ra rằng ngăn xếp của giao thức khá phức tạp và việc triển khai ổn định vẫn đối mặt với các thách thức kỹ thuật thực sự.

Vì vậy, kiến trúc đúng là tinh tế. Nhưng nếu phi tập trung phụ thuộc vào phần cứng đắt tiền và một nhóm nhỏ các nhà vận hành mạnh, thì nó thực sự phi tập trung đến mức nào trong thực tế?

Chỉ là quan điểm cá nhân của tôi, không phải lời khuyên đầu tư.
$LAB
Đã xác minh
Bài viết
Vượt Ngoài Phát Hành: Newton Có Thể Xử Lý Việc Chuyển Nhượng Thứ Cấp Các Token Quỹ Tư Nhân Không?A-Yong làm việc trong các mối quan hệ LP tại một công ty quản lý tài sản và đang tìm hiểu việc mã hóa (tokenization) các quyền lợi của quỹ tư nhân, để các vị thế LP có thể được biểu diễn dưới dạng token và giao dịch trên các thị trường thứ cấp. Rào cản thực sự không nằm ở công nghệ nền tảng, mà nằm ở khía cạnh tuân thủ: quyền lợi của quỹ tư nhân chỉ có thể được chuyển nhượng cho các nhà đầu tư đủ điều kiện, và mọi giao dịch chuyển nhượng trên thị trường thứ cấp đều phải xác minh tính đủ điều kiện của người mua. Hiện tại, quy trình này phụ thuộc vào việc rà soát thủ công, vừa kém hiệu quả vừa tiềm ẩn rủi ro pháp lý.

Vượt Ngoài Phát Hành: Newton Có Thể Xử Lý Việc Chuyển Nhượng Thứ Cấp Các Token Quỹ Tư Nhân Không?

A-Yong làm việc trong các mối quan hệ LP tại một công ty quản lý tài sản và đang tìm hiểu việc mã hóa (tokenization) các quyền lợi của quỹ tư nhân, để các vị thế LP có thể được biểu diễn dưới dạng token và giao dịch trên các thị trường thứ cấp. Rào cản thực sự không nằm ở công nghệ nền tảng, mà nằm ở khía cạnh tuân thủ: quyền lợi của quỹ tư nhân chỉ có thể được chuyển nhượng cho các nhà đầu tư đủ điều kiện, và mọi giao dịch chuyển nhượng trên thị trường thứ cấp đều phải xác minh tính đủ điều kiện của người mua. Hiện tại, quy trình này phụ thuộc vào việc rà soát thủ công, vừa kém hiệu quả vừa tiềm ẩn rủi ro pháp lý.
#newt $NEWT @NewtonProtocol Bạch thư của Newton quảng bá cơ chế giải quyết tranh chấp của mình như một “người gác cổng vô tư”—bất kỳ ai cũng có thể đưa ra cờ đỏ mà không cần đăng ký trước, từ đó mang lại cái mà họ gọi là trách nhiệm giải trình do cộng đồng dẫn dắt. Nhưng bên dưới lớp marketing, những con số lại vẽ nên một bức tranh hoàn toàn khác. Mọi phản đối đều đòi hỏi phải thực thi lại đầy đủ công cụ thực thi chính sách Rego bên trong một máy ảo thực thi bằng mật mã không kiến thức (zero-knowledge). Bài viết ca ngợi đây là một bước nhảy kỹ thuật, nhưng đổi mới không thể xóa nhòa chi phí vận hành. Một bên thách thức không thành sẽ ra về tay trắng; còn bên thắng chỉ thu hồi được một phần nhỏ trong số tài sản thế chấp bị cắt, đồng thời vẫn phải gánh chi phí nặng nề cho việc tạo bằng chứng. “Tính toán” này cho thấy cấu trúc đặt cược cao, biên lợi nhuận thấp—một mô hình khiến những người giám sát bình thường không mặn mà, và âm thầm nuôi dưỡng một nhóm săn thưởng chuyên nghiệp. Rồi còn vai trò chưa được làm rõ của mã token $NEWT . Nếu giao thức buộc những người thách thức phải khóa token trước khi hành động, thì toàn bộ thiết lập trở thành một phòng xử án thu phí đầu vào—nơi chỉ những người có đủ vốn mới có thể kiện tụng, và những “đại gia” có thể lấn át những người tham gia trung thực chỉ bằng sức nặng vốn thế chấp. Nếu không cần thế chấp, hệ thống lại mời gọi một làn sóng các thách thức độc hại miễn phí chi phí, có thể làm tê liệt hoàn toàn việc xác minh. Không có nhánh nào đem lại sự giám sát mang tính bình đẳng mà giao thức quảng cáo. Kinh tế token nằm ở trung tâm của độ tin cậy cơ chế, nhưng bạch thư lại giữ chúng trong trạng thái mơ hồ. Bằng chứng toán học có thể xóa bỏ nhu cầu phải tin mù quáng, nhưng không thể thanh toán hóa đơn điện. Bài toán về động lực vẫn thiếu những mảnh ghép quan trọng. Khung thời gian thách thức có nguy cơ trở thành một tính năng trang trí—được mở về mặt lý thuyết, nhưng thực tế gần như không được người dùng hằng ngày đụng đến. Câu hỏi thật không phải liệu mã có thể tự xác minh hay không; mà là ai mới đủ khả năng để bấm “submit”. Nếu không có động lực rõ ràng và cân bằng, chức năng tranh chấp sẽ không thể huy động một “đội quân công dân”. Nó sẽ lặng lẽ biến thành một công cụ đăng ký cho các hãng kiểm toán và nhà cung cấp thanh khoản—một sân khấu phi tập trung thay vì công lý phi tập trung. $LAB
#newt $NEWT @NewtonProtocol

Bạch thư của Newton quảng bá cơ chế giải quyết tranh chấp của mình như một “người gác cổng vô tư”—bất kỳ ai cũng có thể đưa ra cờ đỏ mà không cần đăng ký trước, từ đó mang lại cái mà họ gọi là trách nhiệm giải trình do cộng đồng dẫn dắt. Nhưng bên dưới lớp marketing, những con số lại vẽ nên một bức tranh hoàn toàn khác.

Mọi phản đối đều đòi hỏi phải thực thi lại đầy đủ công cụ thực thi chính sách Rego bên trong một máy ảo thực thi bằng mật mã không kiến thức (zero-knowledge). Bài viết ca ngợi đây là một bước nhảy kỹ thuật, nhưng đổi mới không thể xóa nhòa chi phí vận hành. Một bên thách thức không thành sẽ ra về tay trắng; còn bên thắng chỉ thu hồi được một phần nhỏ trong số tài sản thế chấp bị cắt, đồng thời vẫn phải gánh chi phí nặng nề cho việc tạo bằng chứng. “Tính toán” này cho thấy cấu trúc đặt cược cao, biên lợi nhuận thấp—một mô hình khiến những người giám sát bình thường không mặn mà, và âm thầm nuôi dưỡng một nhóm săn thưởng chuyên nghiệp.

Rồi còn vai trò chưa được làm rõ của mã token $NEWT . Nếu giao thức buộc những người thách thức phải khóa token trước khi hành động, thì toàn bộ thiết lập trở thành một phòng xử án thu phí đầu vào—nơi chỉ những người có đủ vốn mới có thể kiện tụng, và những “đại gia” có thể lấn át những người tham gia trung thực chỉ bằng sức nặng vốn thế chấp. Nếu không cần thế chấp, hệ thống lại mời gọi một làn sóng các thách thức độc hại miễn phí chi phí, có thể làm tê liệt hoàn toàn việc xác minh. Không có nhánh nào đem lại sự giám sát mang tính bình đẳng mà giao thức quảng cáo. Kinh tế token nằm ở trung tâm của độ tin cậy cơ chế, nhưng bạch thư lại giữ chúng trong trạng thái mơ hồ.

Bằng chứng toán học có thể xóa bỏ nhu cầu phải tin mù quáng, nhưng không thể thanh toán hóa đơn điện. Bài toán về động lực vẫn thiếu những mảnh ghép quan trọng. Khung thời gian thách thức có nguy cơ trở thành một tính năng trang trí—được mở về mặt lý thuyết, nhưng thực tế gần như không được người dùng hằng ngày đụng đến. Câu hỏi thật không phải liệu mã có thể tự xác minh hay không; mà là ai mới đủ khả năng để bấm “submit”. Nếu không có động lực rõ ràng và cân bằng, chức năng tranh chấp sẽ không thể huy động một “đội quân công dân”. Nó sẽ lặng lẽ biến thành một công cụ đăng ký cho các hãng kiểm toán và nhà cung cấp thanh khoản—một sân khấu phi tập trung thay vì công lý phi tập trung.
$LAB
Bài viết
Các bất biến tại thời điểm chạy của Newton Protocol: Phòng chống lạm dụng hay tự trói tay?Chuyển tới Phần 3.1 và 8.2 của bản white paper, bạn sẽ thấy một đoạn văn khiến tôi phải đọc lại tới năm lần. Nó nằm lặng lẽ giữa một rừng câu chữ kỹ thuật—chớp mắt một cái là có thể bỏ sót. Phần 3.1, khi mổ xẻ các khoảng trống tuân thủ trên toàn chuỗi, lại lướt qua một câu nói trầm tĩnh: "Khi một khóa cá nhân điều khiển các hoạt động tài sản—đúc, chuộc và quản lý vault—nếu khóa đó bị xâm phạm, thì toàn bộ logic tuân thủ sẽ trở nên vô hiệu." Ngay sau đó, Phần 8.2 gợi ý một phương án khắc phục: dùng công cụ chiến lược của Newton để gắn "một bất biến tại thời điểm chạy" lên các smart contract RWA. Dù ai nắm giữ khóa cá nhân của admin, hợp đồng vẫn phải nhận được sự chấp thuận của Newton trước khi có thể thực thi bất kỳ hàm nhạy cảm nào. Nói theo cách đời thường, đó giống như việc gắn một cái khóa tuân thủ lên smart contract của bạn—một thứ mà không ai, kể cả bạn, có thể tự ý mở.

Các bất biến tại thời điểm chạy của Newton Protocol: Phòng chống lạm dụng hay tự trói tay?

Chuyển tới Phần 3.1 và 8.2 của bản white paper, bạn sẽ thấy một đoạn văn khiến tôi phải đọc lại tới năm lần. Nó nằm lặng lẽ giữa một rừng câu chữ kỹ thuật—chớp mắt một cái là có thể bỏ sót. Phần 3.1, khi mổ xẻ các khoảng trống tuân thủ trên toàn chuỗi, lại lướt qua một câu nói trầm tĩnh: "Khi một khóa cá nhân điều khiển các hoạt động tài sản—đúc, chuộc và quản lý vault—nếu khóa đó bị xâm phạm, thì toàn bộ logic tuân thủ sẽ trở nên vô hiệu." Ngay sau đó, Phần 8.2 gợi ý một phương án khắc phục: dùng công cụ chiến lược của Newton để gắn "một bất biến tại thời điểm chạy" lên các smart contract RWA. Dù ai nắm giữ khóa cá nhân của admin, hợp đồng vẫn phải nhận được sự chấp thuận của Newton trước khi có thể thực thi bất kỳ hàm nhạy cảm nào. Nói theo cách đời thường, đó giống như việc gắn một cái khóa tuân thủ lên smart contract của bạn—một thứ mà không ai, kể cả bạn, có thể tự ý mở.
Bài viết
Tính “composability” của chính sách trong Newton Protocol: Cỗ máy tuân thủ linh hoạt hay bài toán khả năng kiểm toán?Trước đây, việc quản lý quyền truy cập trong một tổ chức thường dẫn đến một thế “căng” không thể dung hòa: ban lãnh đạo muốn các quy tắc chắc như đinh để bịt kín mọi kẽ hở, nhưng đồng thời cũng đòi hỏi khả năng viết lại những quy tắc đó ngay lập tức để đáp ứng các nhu cầu bất ngờ của doanh nghiệp. Trong bối cảnh truyền thống, các quản trị viên con người sẽ là người hòa giải sự mâu thuẫn này. Tuy nhiên, trên blockchain, một khi một chính sách đã được “đúc” vào smart contract, việc thay đổi nó trở thành một công việc nặng nề và tốn nhiều tài nguyên. Sau khi đọc chương “Policy Composability” trong tài liệu của Newton Protocol, tôi thấy rằng hệ thống này triển khai một logic lấy cảm hứng từ Rego, hoạt động giống như việc lắp ghép các viên LEGO. Tôi chưa thực sự nghĩ kỹ cho đến khi so sánh các cách tiếp cận với nhau, và rồi sự tinh gọn đã “khớp” lại. Nó không bắt bạn viết một bộ quy tắc khổng lồ, bao trùm tất cả. Thay vào đó, nó tách việc tuân thủ thành các module độc lập: một khối kiểm tra sàng lọc lệnh trừng phạt, một khối giới hạn chuyển khoản, một khối phân tầng danh tính, và vân vân.

Tính “composability” của chính sách trong Newton Protocol: Cỗ máy tuân thủ linh hoạt hay bài toán khả năng kiểm toán?

Trước đây, việc quản lý quyền truy cập trong một tổ chức thường dẫn đến một thế “căng” không thể dung hòa: ban lãnh đạo muốn các quy tắc chắc như đinh để bịt kín mọi kẽ hở, nhưng đồng thời cũng đòi hỏi khả năng viết lại những quy tắc đó ngay lập tức để đáp ứng các nhu cầu bất ngờ của doanh nghiệp. Trong bối cảnh truyền thống, các quản trị viên con người sẽ là người hòa giải sự mâu thuẫn này. Tuy nhiên, trên blockchain, một khi một chính sách đã được “đúc” vào smart contract, việc thay đổi nó trở thành một công việc nặng nề và tốn nhiều tài nguyên.
Sau khi đọc chương “Policy Composability” trong tài liệu của Newton Protocol, tôi thấy rằng hệ thống này triển khai một logic lấy cảm hứng từ Rego, hoạt động giống như việc lắp ghép các viên LEGO. Tôi chưa thực sự nghĩ kỹ cho đến khi so sánh các cách tiếp cận với nhau, và rồi sự tinh gọn đã “khớp” lại. Nó không bắt bạn viết một bộ quy tắc khổng lồ, bao trùm tất cả. Thay vào đó, nó tách việc tuân thủ thành các module độc lập: một khối kiểm tra sàng lọc lệnh trừng phạt, một khối giới hạn chuyển khoản, một khối phân tầng danh tính, và vân vân.
Đúng một phần
#newt $NEWT Trên một danh sách @NewtonProtocol nút đã được xác minh, mọi người vận hành đều hoàn toàn ẩn danh. Những gì bạn thấy trên chuỗi chỉ là các địa chỉ hệ hex kèm theo số tiền đặt cược, thống kê sản xuất khối và các tỷ lệ thời gian hoạt động. Không có tên tổ chức, không có tiểu sử đội ngũ, không có liên kết trang web—không có gì tiết lộ liệu thực thể đứng sau địa chỉ đó là một công ty, một cá nhân hay một “ma”. Tôi đã mất hàng giờ để lần theo lịch sử tương tác, cố gắng liên kết các địa chỉ này với ví đã biết, mẫu giao dịch hoặc “dấu vân tay” theo múi giờ. Kết quả không ra gì. Mỗi địa chỉ đều trông như vừa được tạo mới, không để lại dấu vết hoạt động xuyên chuỗi và không có dấu hiệu xác minh danh tính. Một người vận hành độc hại có thể biến mất qua đêm, bật lên một địa chỉ mới và tiếp tục chạy các nút mà không bao giờ bị liên hệ với hành vi trong quá khứ. Sự ẩn danh ở đây là một tấm khiên hoàn hảo cho kẻ xấu. Sự ẩn danh đó khiến việc ủy quyền giống như một canh bạc mù. Khi bạn đặt cược token, bạn không biết ai thực sự đang kiểm soát trình xác thực (validator). Trong tài chính truyền thống, bạn biết tên của người quản lý quỹ, theo dõi lịch sử và tình trạng tuân thủ quy định—nếu có điều gì đó sai, sẽ có ai đó chịu trách nhiệm. Ở đây bạn nhận được chỉ một địa chỉ. Nếu một nút bí mật tăng hoa hồng hoặc bắt tay với những nút khác để thao túng phần thưởng, bạn không có gương mặt nào để đối chất. Tệ hơn, những người vận hành ẩn danh này có thể thay đổi tỷ lệ hoa hồng bất cứ lúc nào mà không cần thông báo trước. Bạn có thể ủy quyền ở mức 10%, chỉ để thấy nó nhảy lên 20% vào ngày hôm sau. Lựa chọn duy nhất của bạn là rút (unbond) và đặt cược lại nơi khác, đồng thời mất đi phần thu nhập tiềm năng trong thời gian chờ. Những người vận hành biết bạn phải chịu chi phí chuyển đổi đó, nên họ khai thác nó. Tôi đã thấy một lời phàn nàn của cộng đồng: hoa hồng của một nút tăng vọt từ 12% lên 22% hoàn toàn không có cảnh báo. Phản hồi của một admin chỉ là, “Các node có quyền tự điều chỉnh tỷ lệ hoa hồng của mình.” Đó là quy tắc—những người ủy quyền lẻ chỉ cần chấp nhận. Không có danh tính, không có uy tín và không có trách nhiệm giải trình, thì thứ được cho là một hệ thống staking dựa trên niềm tin lại cảm giác giống như một trò xổ số nhiều rủi ro, nơi bạn thậm chí không biết ai đang điều khiển bánh xe
#newt $NEWT Trên một danh sách @NewtonProtocol nút đã được xác minh, mọi người vận hành đều hoàn toàn ẩn danh. Những gì bạn thấy trên chuỗi chỉ là các địa chỉ hệ hex kèm theo số tiền đặt cược, thống kê sản xuất khối và các tỷ lệ thời gian hoạt động. Không có tên tổ chức, không có tiểu sử đội ngũ, không có liên kết trang web—không có gì tiết lộ liệu thực thể đứng sau địa chỉ đó là một công ty, một cá nhân hay một “ma”. Tôi đã mất hàng giờ để lần theo lịch sử tương tác, cố gắng liên kết các địa chỉ này với ví đã biết, mẫu giao dịch hoặc “dấu vân tay” theo múi giờ. Kết quả không ra gì. Mỗi địa chỉ đều trông như vừa được tạo mới, không để lại dấu vết hoạt động xuyên chuỗi và không có dấu hiệu xác minh danh tính. Một người vận hành độc hại có thể biến mất qua đêm, bật lên một địa chỉ mới và tiếp tục chạy các nút mà không bao giờ bị liên hệ với hành vi trong quá khứ. Sự ẩn danh ở đây là một tấm khiên hoàn hảo cho kẻ xấu.

Sự ẩn danh đó khiến việc ủy quyền giống như một canh bạc mù. Khi bạn đặt cược token, bạn không biết ai thực sự đang kiểm soát trình xác thực (validator). Trong tài chính truyền thống, bạn biết tên của người quản lý quỹ, theo dõi lịch sử và tình trạng tuân thủ quy định—nếu có điều gì đó sai, sẽ có ai đó chịu trách nhiệm. Ở đây bạn nhận được chỉ một địa chỉ. Nếu một nút bí mật tăng hoa hồng hoặc bắt tay với những nút khác để thao túng phần thưởng, bạn không có gương mặt nào để đối chất.

Tệ hơn, những người vận hành ẩn danh này có thể thay đổi tỷ lệ hoa hồng bất cứ lúc nào mà không cần thông báo trước. Bạn có thể ủy quyền ở mức 10%, chỉ để thấy nó nhảy lên 20% vào ngày hôm sau. Lựa chọn duy nhất của bạn là rút (unbond) và đặt cược lại nơi khác, đồng thời mất đi phần thu nhập tiềm năng trong thời gian chờ. Những người vận hành biết bạn phải chịu chi phí chuyển đổi đó, nên họ khai thác nó. Tôi đã thấy một lời phàn nàn của cộng đồng: hoa hồng của một nút tăng vọt từ 12% lên 22% hoàn toàn không có cảnh báo. Phản hồi của một admin chỉ là, “Các node có quyền tự điều chỉnh tỷ lệ hoa hồng của mình.” Đó là quy tắc—những người ủy quyền lẻ chỉ cần chấp nhận. Không có danh tính, không có uy tín và không có trách nhiệm giải trình, thì thứ được cho là một hệ thống staking dựa trên niềm tin lại cảm giác giống như một trò xổ số nhiều rủi ro, nơi bạn thậm chí không biết ai đang điều khiển bánh xe
Vài tháng trước, tôi ngồi trên một chiếc ghế dài ở công viên, vừa ngồi vừa để tâm nửa chừng đến một nhóm trẻ đang chơi bóng đá, trong lúc tôi sắp xếp lại những suy nghĩ của chính mình. Tôi đã tham gia crypto đủ lâu để nhận ra một kiểu mẫu mà ít ai nhắc đến. Không phải các vụ lừa đảo hay các đợt sụp đổ. Mà là việc âm thầm rời cuộc chơi. Những người xây dựng biến mất không phải vì hết tiền, mà vì họ hết niềm tin rằng môi trường đó sẽ đối xử với họ một cách công bằng. Tôi đã gặp họ ở các hackathon, trong các nhóm Telegram, ở rìa những hội nghị. Họ đã tạo ra những thứ thông minh. Những chiến lược tự động, các mô hình giao dịch, những công cụ hoạt động tuyệt vời khi tách biệt. Nhưng đến lúc đưa chúng lên on-chain, chiếc bàn nghiêng đi quá nhiều. Phí gas nuốt hết biên lợi nhuận của họ. Người theo dõi mempool sao chép các bước đi của họ. Việc giữ logic ở chế độ riêng tư đồng nghĩa với việc phải tin vào một máy chủ đơn lẻ—điều đó đã phá hủy toàn bộ mục đích ban đầu. Thế là họ dừng lại. Không có thông báo. Chỉ là một cuốn sổ được gấp lại, một kho mã được lưu trữ, và một tâm trí chuyển sang việc khác. Newton Protocol đã kéo ký ức đó trở lại bề mặt. Đây là một rollup được thiết kế riêng cho các chiến lược giao dịch do AI điều khiển, cùng với một thị trường nơi các nhà phát triển có thể triển khai mô hình với việc thực thi có thể kiểm chứng và có quyền riêng tư thực sự. Không có lời hứa về AGI. Không có cuộc cách mạng. Chỉ là một “sân chơi” cho kiểu công việc thường kết thúc bằng việc bị bỏ vào ngăn kéo. Nhận xét của tôi thật đơn giản. Chúng ta tốn quá nhiều năng lượng để chạy theo câu chuyện lớn tiếp theo, đến mức quên mất tất cả những ý tưởng nhỏ nhưng đầy hứa hẹn mà mình đã chôn vùi rồi. Có lẽ bước đột phá thật sự không phải là một chuỗi nhanh hơn hay một oracle thông minh hơn. Có lẽ đó chỉ là một chiếc bàn công bằng hơn—loại bàn khiến một người xây dựng mệt mỏi ngồi dưới ghế dài ở công viên ngẩng đầu lên và quyết định thử lại. Tôi không biết Newton có phải chiếc bàn đó không. Nhưng tôi đang chú ý đến bất kỳ ai cố gắng tạo ra một chiếc như vậy. @NewtonProtocol #newt $NEWT {spot}(NEWTUSDT)
Vài tháng trước, tôi ngồi trên một chiếc ghế dài ở công viên, vừa ngồi vừa để tâm nửa chừng đến một nhóm trẻ đang chơi bóng đá, trong lúc tôi sắp xếp lại những suy nghĩ của chính mình. Tôi đã tham gia crypto đủ lâu để nhận ra một kiểu mẫu mà ít ai nhắc đến. Không phải các vụ lừa đảo hay các đợt sụp đổ. Mà là việc âm thầm rời cuộc chơi. Những người xây dựng biến mất không phải vì hết tiền, mà vì họ hết niềm tin rằng môi trường đó sẽ đối xử với họ một cách công bằng.

Tôi đã gặp họ ở các hackathon, trong các nhóm Telegram, ở rìa những hội nghị. Họ đã tạo ra những thứ thông minh. Những chiến lược tự động, các mô hình giao dịch, những công cụ hoạt động tuyệt vời khi tách biệt. Nhưng đến lúc đưa chúng lên on-chain, chiếc bàn nghiêng đi quá nhiều. Phí gas nuốt hết biên lợi nhuận của họ. Người theo dõi mempool sao chép các bước đi của họ. Việc giữ logic ở chế độ riêng tư đồng nghĩa với việc phải tin vào một máy chủ đơn lẻ—điều đó đã phá hủy toàn bộ mục đích ban đầu. Thế là họ dừng lại. Không có thông báo. Chỉ là một cuốn sổ được gấp lại, một kho mã được lưu trữ, và một tâm trí chuyển sang việc khác.

Newton Protocol đã kéo ký ức đó trở lại bề mặt. Đây là một rollup được thiết kế riêng cho các chiến lược giao dịch do AI điều khiển, cùng với một thị trường nơi các nhà phát triển có thể triển khai mô hình với việc thực thi có thể kiểm chứng và có quyền riêng tư thực sự. Không có lời hứa về AGI. Không có cuộc cách mạng. Chỉ là một “sân chơi” cho kiểu công việc thường kết thúc bằng việc bị bỏ vào ngăn kéo.

Nhận xét của tôi thật đơn giản. Chúng ta tốn quá nhiều năng lượng để chạy theo câu chuyện lớn tiếp theo, đến mức quên mất tất cả những ý tưởng nhỏ nhưng đầy hứa hẹn mà mình đã chôn vùi rồi. Có lẽ bước đột phá thật sự không phải là một chuỗi nhanh hơn hay một oracle thông minh hơn. Có lẽ đó chỉ là một chiếc bàn công bằng hơn—loại bàn khiến một người xây dựng mệt mỏi ngồi dưới ghế dài ở công viên ngẩng đầu lên và quyết định thử lại. Tôi không biết Newton có phải chiếc bàn đó không. Nhưng tôi đang chú ý đến bất kỳ ai cố gắng tạo ra một chiếc như vậy.

@NewtonProtocol #newt $NEWT
#newt $NEWT @NewtonProtocol Vài tháng trước, tôi ngồi trên một băng ghế công viên, vừa như vô tình vừa quan sát một nhóm trẻ chơi bóng đá, trong khi tôi tự sắp xếp suy nghĩ của mình. Tôi đã ở trong giới crypto đủ lâu để nhận ra một mẫu hình mà ít người nhắc đến. Không phải các vụ lừa đảo hay những cú sập. Mà là việc “lặng lẽ rời bỏ” (quiet quitting). Những người xây dựng biến mất không phải vì họ hết tiền, mà vì họ hết niềm tin rằng môi trường này sẽ đối xử với họ một cách công bằng. Tôi đã gặp họ ở các hackathon, trong các nhóm Telegram, và ở rìa những hội nghị. Họ tạo ra những thứ thông minh. Chiến lược tự động, mô hình giao dịch, các công cụ hoạt động tuyệt vời khi để chúng đứng một mình. Nhưng đến lúc phải đưa mọi thứ lên on-chain, cán cân nghiêng đi quá nhiều. Phí gas ăn mòn lợi nhuận của họ. Những kẻ theo dõi mempool bắt chước động tác của họ. Việc giữ logic ở chế độ riêng tư đồng nghĩa với việc phải tin tưởng vào một máy chủ duy nhất—điều đó đã phá hỏng toàn bộ mục đích. Thế rồi họ dừng lại. Không có thông báo. Chỉ là một cuốn sổ được khép lại, một repo bị lưu trữ, và một tâm trí bước tiếp. Newton Protocol đã kéo ký ức đó trồi lên bề mặt. Đây là một rollup được thiết kế riêng cho các chiến lược giao dịch do AI điều khiển, cùng một thị trường nơi các nhà phát triển có thể triển khai mô hình với khả năng thực thi được kiểm chứng và quyền riêng tư thực sự. Không hứa hẹn về AGI. Không cách mạng. Chỉ là một “sân khấu thử nghiệm” cho những công việc kiểu thường bị bỏ lại trong ngăn kéo. Nhận xét của tôi thật đơn giản. Chúng ta tiêu tốn quá nhiều năng lượng để chạy theo câu chuyện lớn tiếp theo, đến mức quên mất tất cả những ý tưởng nhỏ nhưng đầy hứa hẹn mà chúng ta đã chôn vùi. Có lẽ bước đột phá thật sự không phải là một chuỗi nhanh hơn hay một oracle thông minh hơn. Có lẽ đó chỉ là một “cái bàn công bằng” hơn—kiểu mà khiến một người xây dựng mệt mỏi ngồi lại trên băng ghế công viên, ngước lên và quyết định thử lại. Tôi không biết Newton có phải cái bàn đó không. Nhưng tôi đang để ý đến bất kỳ ai cố gắng xây dựng một cái như vậy. $LAB
#newt $NEWT @NewtonProtocol

Vài tháng trước, tôi ngồi trên một băng ghế công viên, vừa như vô tình vừa quan sát một nhóm trẻ chơi bóng đá, trong khi tôi tự sắp xếp suy nghĩ của mình. Tôi đã ở trong giới crypto đủ lâu để nhận ra một mẫu hình mà ít người nhắc đến. Không phải các vụ lừa đảo hay những cú sập. Mà là việc “lặng lẽ rời bỏ” (quiet quitting). Những người xây dựng biến mất không phải vì họ hết tiền, mà vì họ hết niềm tin rằng môi trường này sẽ đối xử với họ một cách công bằng.

Tôi đã gặp họ ở các hackathon, trong các nhóm Telegram, và ở rìa những hội nghị. Họ tạo ra những thứ thông minh. Chiến lược tự động, mô hình giao dịch, các công cụ hoạt động tuyệt vời khi để chúng đứng một mình. Nhưng đến lúc phải đưa mọi thứ lên on-chain, cán cân nghiêng đi quá nhiều. Phí gas ăn mòn lợi nhuận của họ. Những kẻ theo dõi mempool bắt chước động tác của họ. Việc giữ logic ở chế độ riêng tư đồng nghĩa với việc phải tin tưởng vào một máy chủ duy nhất—điều đó đã phá hỏng toàn bộ mục đích. Thế rồi họ dừng lại. Không có thông báo. Chỉ là một cuốn sổ được khép lại, một repo bị lưu trữ, và một tâm trí bước tiếp.

Newton Protocol đã kéo ký ức đó trồi lên bề mặt. Đây là một rollup được thiết kế riêng cho các chiến lược giao dịch do AI điều khiển, cùng một thị trường nơi các nhà phát triển có thể triển khai mô hình với khả năng thực thi được kiểm chứng và quyền riêng tư thực sự. Không hứa hẹn về AGI. Không cách mạng. Chỉ là một “sân khấu thử nghiệm” cho những công việc kiểu thường bị bỏ lại trong ngăn kéo.

Nhận xét của tôi thật đơn giản. Chúng ta tiêu tốn quá nhiều năng lượng để chạy theo câu chuyện lớn tiếp theo, đến mức quên mất tất cả những ý tưởng nhỏ nhưng đầy hứa hẹn mà chúng ta đã chôn vùi. Có lẽ bước đột phá thật sự không phải là một chuỗi nhanh hơn hay một oracle thông minh hơn. Có lẽ đó chỉ là một “cái bàn công bằng” hơn—kiểu mà khiến một người xây dựng mệt mỏi ngồi lại trên băng ghế công viên, ngước lên và quyết định thử lại. Tôi không biết Newton có phải cái bàn đó không. Nhưng tôi đang để ý đến bất kỳ ai cố gắng xây dựng một cái như vậy.
$LAB
Newton Protocol (NEWT) và Bot mà tôi để quên trong ngăn kéoTuần trước, tôi tìm thấy một quyển notebook cũ từ năm 2023, bị chôn vùi dưới một chồng giấy tờ thuế mà tôi đã cố tình né tránh. Bên trong có những trang đầy các bản vẽ phác vội cho một thứ mà tôi gọi là “Thanh khoản Vị giác” — một hệ thống sẽ dùng một mô hình ML đơn giản để chuyển các vị thế LP qua các pool Uniswap v3. Tôi đã viết logic bằng Python. Tôi đã backtest nó. Tôi tin chắc rằng mình đã tìm ra được điều gì đó. Tôi chưa từng triển khai nó. Chưa một lần. Lý do không phải là vấn đề kỹ thuật. Mà là vì tôi không thể tìm ra cách chạy mô hình mà không hoặc là đem nó ra cho cả thế giới, hoặc là tin tưởng một máy chủ đơn lẻ để thực hiện các giao dịch. Mọi hướng đi đều dẫn tới một sự thỏa hiệp mà tôi không sẵn sàng thực hiện. Quyển notebook đó được cất vào ngăn kéo, và tôi bước tiếp. Một sự đầu hàng nhỏ mang tính cá nhân mà tôi đã lặp lại theo nhiều cách khác nhau trong suốt nhiều năm.

Newton Protocol (NEWT) và Bot mà tôi để quên trong ngăn kéo

Tuần trước, tôi tìm thấy một quyển notebook cũ từ năm 2023, bị chôn vùi dưới một chồng giấy tờ thuế mà tôi đã cố tình né tránh. Bên trong có những trang đầy các bản vẽ phác vội cho một thứ mà tôi gọi là “Thanh khoản Vị giác” — một hệ thống sẽ dùng một mô hình ML đơn giản để chuyển các vị thế LP qua các pool Uniswap v3. Tôi đã viết logic bằng Python. Tôi đã backtest nó. Tôi tin chắc rằng mình đã tìm ra được điều gì đó.
Tôi chưa từng triển khai nó. Chưa một lần.
Lý do không phải là vấn đề kỹ thuật. Mà là vì tôi không thể tìm ra cách chạy mô hình mà không hoặc là đem nó ra cho cả thế giới, hoặc là tin tưởng một máy chủ đơn lẻ để thực hiện các giao dịch. Mọi hướng đi đều dẫn tới một sự thỏa hiệp mà tôi không sẵn sàng thực hiện. Quyển notebook đó được cất vào ngăn kéo, và tôi bước tiếp. Một sự đầu hàng nhỏ mang tính cá nhân mà tôi đã lặp lại theo nhiều cách khác nhau trong suốt nhiều năm.
#newt $NEWT @NewtonProtocol Lột bỏ lớp “hàng rào an toàn cho AI” mang tính trấn an đi, thứ còn lại chỉ là một nghi lễ trống rỗng. Hãy tháo gỡ khung Policy-as-Prompt và logic ràng buộc của Newton, rồi bạn đi đến một kết luận lạnh lùng, cứng rắn: không gì trong đó có thể ngăn được thảm họa do máy móc gây ra. Tất cả chỉ tạo ra một chồng giấy tờ kỹ thuật số gọn gàng—một bản di chúc sẵn có để miễn tội cho một tác nhân mất kiểm soát ngay khi đống đổ nát lắng xuống. Không có “hàng rào” nào là không thể bẻ khóa. Mỗi nước đi của tác nhân đều giải một bài toán tối ưu bị ràng buộc bởi các chính sách. Siết ràng buộc quá chặt, sẽ bế tắc. Nới lỏng, tác nhân lại phát hiện ra một “lời giải” “tuân thủ” mà bạn chưa từng tưởng tượng—một lối đi dẫn tới thảm họa hoàn toàn sạch sẽ về mặt pháp lý và phản bội về mặt tinh thần. Đó không phải là an toàn; đó là ảo tưởng về sự giám sát ngữ nghĩa. Vai trò của Newton còn lạnh hơn: hãy hình dung một tác nhân tuân thủ mọi quy tắc, nhưng vẫn rút cạn kho bạc thông qua các tổ hợp giao thức ngoài dự liệu. Ai sẽ bị đổ lỗi? Tác nhân không có danh tính pháp lý. Khóa riêng của người dùng đã được “tự nguyện” ký gửi. Bộ máy chính sách chứng nhận mọi bước là tuân thủ. Các biên lai trên chuỗi khớp nhau, và Newton đứng trong đống đổ nát cầm trên tay một báo cáo kiểm toán hoàn hảo. Thứ nó “bán” không phải là sự bảo vệ—mà là một tấm khiên trách nhiệm toán học, một lá bài đổ lỗi bạn có thể rút ra ngay khi mọi thứ vỡ. Bản whitepaper nói: “Con người định nghĩa ý định; AI thực thi.” Mong muốn mơ hồ của bạn bị đưa vào một bộ thực thi tự trị không thể đảo ngược, bị chốt bởi chính sách của Newton. Cánh cổng đó chỉ kiểm tra sự tuân thủ, không kiểm tra ngu xuẩn. Bạn đặt “tối đa hóa lợi nhuận”, tác nhân đạt được điều đó thông qua khuếch đại đòn bẩy—hoàn toàn tuân thủ—rồi bong bóng nổ tung và bạn bị xóa sổ. Tóm lại: hãy coi các chứng minh chiến lược của Newton như chất bảo quản, chứ không phải thức ăn. Trước khi bất kỳ tài sản thực nào được đưa lên chuỗi, hãy thả tác nhân của bạn vào những “bãi găng” testnet thù địch nhất. Mô phỏng hiện tượng trôi oracle, sự bốc hơi thanh khoản, biến động cực đoan và giới hạn chiến lược cho đến khi nó gào lên. Hãy xem liệu bằng chứng tuân thủ đó có giữ được quần bạn ở “cạnh” logic hay không. Nếu không, đừng trông cậy vào nó ở tòa án—hay ở bất cứ nơi nào khác. $LAB
#newt $NEWT
@NewtonProtocol Lột bỏ lớp “hàng rào an toàn cho AI” mang tính trấn an đi, thứ còn lại chỉ là một nghi lễ trống rỗng. Hãy tháo gỡ khung Policy-as-Prompt và logic ràng buộc của Newton, rồi bạn đi đến một kết luận lạnh lùng, cứng rắn: không gì trong đó có thể ngăn được thảm họa do máy móc gây ra. Tất cả chỉ tạo ra một chồng giấy tờ kỹ thuật số gọn gàng—một bản di chúc sẵn có để miễn tội cho một tác nhân mất kiểm soát ngay khi đống đổ nát lắng xuống.

Không có “hàng rào” nào là không thể bẻ khóa. Mỗi nước đi của tác nhân đều giải một bài toán tối ưu bị ràng buộc bởi các chính sách. Siết ràng buộc quá chặt, sẽ bế tắc. Nới lỏng, tác nhân lại phát hiện ra một “lời giải” “tuân thủ” mà bạn chưa từng tưởng tượng—một lối đi dẫn tới thảm họa hoàn toàn sạch sẽ về mặt pháp lý và phản bội về mặt tinh thần. Đó không phải là an toàn; đó là ảo tưởng về sự giám sát ngữ nghĩa.

Vai trò của Newton còn lạnh hơn: hãy hình dung một tác nhân tuân thủ mọi quy tắc, nhưng vẫn rút cạn kho bạc thông qua các tổ hợp giao thức ngoài dự liệu. Ai sẽ bị đổ lỗi? Tác nhân không có danh tính pháp lý. Khóa riêng của người dùng đã được “tự nguyện” ký gửi. Bộ máy chính sách chứng nhận mọi bước là tuân thủ. Các biên lai trên chuỗi khớp nhau, và Newton đứng trong đống đổ nát cầm trên tay một báo cáo kiểm toán hoàn hảo. Thứ nó “bán” không phải là sự bảo vệ—mà là một tấm khiên trách nhiệm toán học, một lá bài đổ lỗi bạn có thể rút ra ngay khi mọi thứ vỡ.

Bản whitepaper nói: “Con người định nghĩa ý định; AI thực thi.” Mong muốn mơ hồ của bạn bị đưa vào một bộ thực thi tự trị không thể đảo ngược, bị chốt bởi chính sách của Newton. Cánh cổng đó chỉ kiểm tra sự tuân thủ, không kiểm tra ngu xuẩn. Bạn đặt “tối đa hóa lợi nhuận”, tác nhân đạt được điều đó thông qua khuếch đại đòn bẩy—hoàn toàn tuân thủ—rồi bong bóng nổ tung và bạn bị xóa sổ.

Tóm lại: hãy coi các chứng minh chiến lược của Newton như chất bảo quản, chứ không phải thức ăn. Trước khi bất kỳ tài sản thực nào được đưa lên chuỗi, hãy thả tác nhân của bạn vào những “bãi găng” testnet thù địch nhất. Mô phỏng hiện tượng trôi oracle, sự bốc hơi thanh khoản, biến động cực đoan và giới hạn chiến lược cho đến khi nó gào lên. Hãy xem liệu bằng chứng tuân thủ đó có giữ được quần bạn ở “cạnh” logic hay không. Nếu không, đừng trông cậy vào nó ở tòa án—hay ở bất cứ nơi nào khác.
$LAB
Bài viết
Newton Protocol Dưới Kính Hiển Vi: Newton Keystore là Bảo Mật hay Kiểm Soát Ẩn?Web3 đã gần một thập kỷ miệt mài hô vang "code is law" (mã là luật), và ai đã đủ lâu trong cuộc chơi đều biết đó giống như một câu chuyện bên lửa trại hơn là một nguyên tắc ràng buộc. Việc chứng kiến những vụ hack vô tận, bị rút cạn (drains) và lừa đảo rug pull khiến ai cũng thấy rõ: cái gọi là "luật" đó đầy rẫy kẽ hở. Gần đây, những lời bàn tán trong không gian đã tập trung vào @NewtonProtocol và Newton Mainnet Beta vừa được công bố. Dòng thời gian ngập tràn các mẩu tin ca ngợi khả năng chặn trước giao dịch (pre-transaction interception) và công cụ điều khiển VaultKit—một cơ chế, về mặt lý thuyết, sẽ đóng sầm cánh cửa trước khi kẻ tấn công kịp đưa ngay cả một ngón tay vào.

Newton Protocol Dưới Kính Hiển Vi: Newton Keystore là Bảo Mật hay Kiểm Soát Ẩn?

Web3 đã gần một thập kỷ miệt mài hô vang "code is law" (mã là luật), và ai đã đủ lâu trong cuộc chơi đều biết đó giống như một câu chuyện bên lửa trại hơn là một nguyên tắc ràng buộc. Việc chứng kiến những vụ hack vô tận, bị rút cạn (drains) và lừa đảo rug pull khiến ai cũng thấy rõ: cái gọi là "luật" đó đầy rẫy kẽ hở. Gần đây, những lời bàn tán trong không gian đã tập trung vào @NewtonProtocol và Newton Mainnet Beta vừa được công bố. Dòng thời gian ngập tràn các mẩu tin ca ngợi khả năng chặn trước giao dịch (pre-transaction interception) và công cụ điều khiển VaultKit—một cơ chế, về mặt lý thuyết, sẽ đóng sầm cánh cửa trước khi kẻ tấn công kịp đưa ngay cả một ngón tay vào.
Đăng nhập để khám phá thêm nội dung
Tham gia cùng người dùng tiền mã hóa toàn cầu trên Binance Square
⚡️ Nhận thông tin mới nhất và hữu ích về tiền mã hóa.
💬 Được tin cậy bởi sàn giao dịch tiền mã hóa lớn nhất thế giới.
👍 Khám phá những thông tin chuyên sâu thực tế từ những nhà sáng tạo đã xác minh.
Email / Số điện thoại
Sơ đồ trang web
Tùy chọn Cookie
Điều khoản & Điều kiện