Eric Choo

🎉 Chính thức lọt Top 100 CreatorPad!

Thật sự cảm ơn tất cả mọi người đã luôn đọc bài, tương tác và đồng hành cùng mình trong suốt thời gian qua 🫶
Từ những bài chia sẻ đơn giản về market, mindset đến góc nhìn cá nhân, mình không nghĩ có ngày lại nhận được thành quả này.

15489 $PIXEL không chỉ là phần thưởng, mà còn là động lực để mình tiếp tục tạo ra nhiều nội dung chất lượng hơn cho cộng đồng 🚀

Hành trình vẫn còn dài, cố gắng giữ vững phong độ và tiến xa hơn nữa 💛
Anh em nào đang build content thì cứ kiên trì nhé, cơ hội luôn có cho người làm thật.

#CreatorpadVN #BinanceSquare

PIXEL+2,90%

PINNED

Không nghĩ lần này mình lại may mắn vào được top 4 CreatorPad VN trên Binance Square 🥹
Phần thưởng 0.12 $BNB không quá lớn nhưng là động lực để tiếp tục viết và chia sẻ nhiều hơn.

Thật ra mình thấy Binance Square vẫn còn khá nhiều cơ hội cho anh em thích viết content, phân tích hoặc đơn giản là chăm tương tác mỗi ngày.
Cứ bắt đầu thử thôi, biết đâu bài tiếp theo của bạn lại lên top 👀

Ai đang muốn tham gia mà chưa biết bắt đầu từ đâu, cần tips viết bài, cách build tương tác hay săn event thì cứ hỏi mình, mình support được gì sẽ support hết 🤝

Chúc mừng anh em đợt này có quà nhé 🫶

BNB+0,66%

#binancep2pantoan @Binance Vietnam

Bức Ảnh Chụp Suýt Đánh Lừa Tôi

Tôi từng có một người mua gửi cho tôi một ảnh chụp thanh toán trông “hoàn hảo” — đúng số tiền, đúng ngân hàng, đúng thời điểm. Tôi suýt đã chuyển hàng. Rồi tôi nhớ đến một nguyên tắc mà tôi đã từng hứa với chính mình sẽ không bao giờ phá: mở ứng dụng ngân hàng của mình, không phải ứng dụng của họ. Không có khoản nào được nhận. Ảnh chụp đó là giả.

Giao dịch đó dạy tôi nhiều hơn bất kỳ hướng dẫn nào. Giờ đây tôi kiểm tra tỷ lệ hoàn thành và lịch sử đơn hàng của bên đối tác trước khi thậm chí đồng ý giao dịch — không chỉ nhìn vào huy hiệu. Mỗi lần tôi đều đối chiếu tên người thanh toán với chi tiết đơn hàng. Và khi một người mua đột nhiên nhờ tôi “hoàn tất trên Zalo, nhanh hơn” — đó là lúc tôi phải chậm lại, không phải tăng tốc. Giao dịch hợp lệ không bao giờ cần phải rời khỏi nền tảng.

Dù là các giao dịch có vẻ hoàn toàn thông thường, tôi vẫn luôn lưu toàn bộ Mã đơn hàng và lịch sử chat sau khi đóng giao dịch. Có đúng một lần tôi cần đến, việc mọi thứ đã được lưu sẵn đã biến một tranh chấp căng thẳng thành hướng giải quyết trong cùng ngày.

Hãy tin vào các kiểm tra của nền tảng, không phải một ảnh chụp.

#binancep2pantoan @Binance Vietnam

Mười giây tôi suýt bỏ qua

Giao dịch P2P đầu tiên của tôi diễn ra gần như ngay lập tức. Ký quỹ khóa crypto của bên bán trước khi tôi chuyển đúng một đồng, chat ghi lại từng tin nhắn, và kênh tranh chấp chỉ cách một thao tác nếu có bất kỳ sự cố nào. Tất cả những thứ đó không tồn tại ngoài nền tảng — không ký quỹ, không lịch sử chat, không có quyền truy cập hỗ trợ. Đó không phải là một quy định, đó là sự xóa bỏ.

Tôi hiện kiểm tra ba thứ. Đối tác: huy hiệu, tỷ lệ hoàn thành, lịch sử đơn — không chỉ nhìn mỗi cái tên. Thanh toán: ứng dụng ngân hàng của chính tôi xác nhận tiền đã vào, không bao giờ là ảnh chụp màn hình. Áp lực: yêu cầu phát hành vội vàng, đổi tài khoản khi đang giao dịch, một đề nghị “chuyển cái này sang Zalo” — chỉ cần một trong các lý do đó cũng đủ để dừng lại; hai cái cùng lúc là lý do để mở tranh chấp.

Tôi lưu Order ID, biên nhận và bản ghi hội thoại sau mỗi giao dịch. Trước đây chưa từng cần. Cho đến một lần, tôi đã cần.

Câu hỏi thật không phải là liệu P2P có an toàn hay không. Mà là trong lúc bạn đang vội, bạn sẽ bỏ qua kiểm tra nào trong số những bước đó.

#baby $BABY @babylonlabs_io Từ rất lâu trước khi có tất cả những điều này, tôi đã từng viết về việc mọi người mặc định chọn nhà cung cấp cuối cùng (finality) hàng đầu mà không hề kiểm tra. Thực ra tôi chưa từng tự mình kiểm tra các con số phân bổ thực tế; tôi chỉ làm việc dựa trên giai thoại. Vì vậy, tôi đã đi và trích xuất cơ cấu stake thực tế giữa các nhà cung cấp để xem mức độ tệ đến đâu. Kết quả tệ hơn ở một điểm và tốt hơn ở một điểm so với những gì tôi dự đoán. Một vài nhà cung cấp đứng đầu nắm giữ tỷ trọng không tương xứng—phần này đúng với giả định của tôi. Điều khiến tôi bất ngờ là đường cong mức độ tập trung phẳng đi nhanh đến thế sau vài nhà cung cấp đầu tiên: một “đuôi dài” của các nhà cung cấp nhỏ hơn, mỗi bên đều nắm giữ lượng stake đáng kể, không phải bức tranh kiểu “ai cũng dồn hết vào một cái tên” như giai thoại trong group chat đã ngụ ý. Vấn đề không phải là một nhà cung cấp thống trị duy nhất; đó là một lớp trên cùng được tập trung ở mức vừa phải, nằm trên một “đuôi dài” thực sự rất dài mà hầu hết người ủy thác không bao giờ cuộn xuống xem. Góc nhìn kỹ thuật: sự khác biệt này quan trọng cho việc “khắc phục” thực sự có nghĩa là gì. Nếu chỉ có một nhà cung cấp thống trị, thì cách sửa khá rõ ràng—cắt giảm sự tập trung đó. Còn với đường cong đã phẳng, hệ thống vốn đã phi tập trung hơn những quan sát thông thường. Khoảng trống thực sự nằm giữa những gì tồn tại và những gì người ủy thác tưởng rằng tồn tại, vì gần như tất cả những người tôi đã nói chuyện đều mô tả nó là tập trung hơn so với dữ liệu cho thấy. Tự phê bình: tôi viết bài ban đầu từ một giai thoại duy nhất và cảm nhận chung, chứ không phải từ việc rút ra các con số thực. Tôi lẽ ra nên kiểm tra sớm hơn thay vì cứ giả định phiên bản “xấu nhất” là phiên bản đúng. Dữ liệu thực tế làm câu chuyện thay đổi—không phải thành “không có vấn đề gì”, mà thành một câu chuyện hẹp hơn, chính xác hơn. Câu chuyện về bảo mật của $BABY sẽ thuyết phục hơn nếu dựa vào dữ liệu phân bổ thực tế này, thay vì để mọi người suy đoán dựa trên việc những cái tên nào được nhắc đến nhiều nhất. Tôi muốn Babylon hiển thị trực tiếp đường cong phân bổ này ngay trong giao diện staking, vì hiện tại bạn phải tự đi đào để tìm nó, giống như tôi vừa làm. #baby ⚠️ Không phải lời khuyên tài chính. Hãy tự nghiên cứu (DYOR).

#baby $BABY @BabylonLabs_io

Từ rất lâu trước khi có tất cả những điều này, tôi đã từng viết về việc mọi người mặc định chọn nhà cung cấp cuối cùng (finality) hàng đầu mà không hề kiểm tra. Thực ra tôi chưa từng tự mình kiểm tra các con số phân bổ thực tế; tôi chỉ làm việc dựa trên giai thoại. Vì vậy, tôi đã đi và trích xuất cơ cấu stake thực tế giữa các nhà cung cấp để xem mức độ tệ đến đâu.

Kết quả tệ hơn ở một điểm và tốt hơn ở một điểm so với những gì tôi dự đoán.

Một vài nhà cung cấp đứng đầu nắm giữ tỷ trọng không tương xứng—phần này đúng với giả định của tôi. Điều khiến tôi bất ngờ là đường cong mức độ tập trung phẳng đi nhanh đến thế sau vài nhà cung cấp đầu tiên: một “đuôi dài” của các nhà cung cấp nhỏ hơn, mỗi bên đều nắm giữ lượng stake đáng kể, không phải bức tranh kiểu “ai cũng dồn hết vào một cái tên” như giai thoại trong group chat đã ngụ ý. Vấn đề không phải là một nhà cung cấp thống trị duy nhất; đó là một lớp trên cùng được tập trung ở mức vừa phải, nằm trên một “đuôi dài” thực sự rất dài mà hầu hết người ủy thác không bao giờ cuộn xuống xem.

Góc nhìn kỹ thuật: sự khác biệt này quan trọng cho việc “khắc phục” thực sự có nghĩa là gì. Nếu chỉ có một nhà cung cấp thống trị, thì cách sửa khá rõ ràng—cắt giảm sự tập trung đó. Còn với đường cong đã phẳng, hệ thống vốn đã phi tập trung hơn những quan sát thông thường. Khoảng trống thực sự nằm giữa những gì tồn tại và những gì người ủy thác tưởng rằng tồn tại, vì gần như tất cả những người tôi đã nói chuyện đều mô tả nó là tập trung hơn so với dữ liệu cho thấy.

Tự phê bình: tôi viết bài ban đầu từ một giai thoại duy nhất và cảm nhận chung, chứ không phải từ việc rút ra các con số thực. Tôi lẽ ra nên kiểm tra sớm hơn thay vì cứ giả định phiên bản “xấu nhất” là phiên bản đúng. Dữ liệu thực tế làm câu chuyện thay đổi—không phải thành “không có vấn đề gì”, mà thành một câu chuyện hẹp hơn, chính xác hơn.

Câu chuyện về bảo mật của $BABY sẽ thuyết phục hơn nếu dựa vào dữ liệu phân bổ thực tế này, thay vì để mọi người suy đoán dựa trên việc những cái tên nào được nhắc đến nhiều nhất.

Tôi muốn Babylon hiển thị trực tiếp đường cong phân bổ này ngay trong giao diện staking, vì hiện tại bạn phải tự đi đào để tìm nó, giống như tôi vừa làm. #baby

⚠️ Không phải lời khuyên tài chính. Hãy tự nghiên cứu (DYOR).

#baby $BABY @babylonlabs_io Sau khi viết về việc giảm phát thải và liệu doanh thu phí có thể bù đắp phần chênh lệch mà nó để lại hay không, tôi bắt đầu tìm các con số thực tế thay vì để mối lo chỉ dừng ở mức trừu tượng. Tôi muốn biết nơi Babylon công bố đường cong phát thải và, lý tưởng nhất, là một số dự phóng về doanh thu dựa trên mức sử dụng so với đường cong đó. Tôi đã tìm được lịch phát thải mà không gặp mấy khó khăn—các bảng dữ liệu nêu rõ lượng phát hành theo từng kỳ, các tỷ lệ suy giảm, mọi thứ đều được trình bày khá rõ ràng. Thứ tôi không thể tìm thấy là nửa còn lại của phương trình. Không có gì thể hiện việc đối chiếu lịch phát thải đó với khối lượng vay TBV dự kiến hoặc với doanh thu phí staking, cũng không có mô hình nào cho thấy thời điểm người ta chuyển giao từ phần này sang phần kia. Tôi đã kiểm tra các bài đăng về quản trị, các cập nhật blog, thậm chí tìm kiếm mọi bình luận của đội ngũ về chủ đề này. Có rất nhiều thảo luận về tăng trưởng và mức độ áp dụng, nhưng không có gì được đóng khung theo kiểu: "đây là dữ liệu mức sử dụng cần phải như thế nào cho tới khi phát thải giảm xuống còn X". Điểm kỹ thuật: công bố lịch phát thải là một mốc minh bạch cơ bản—gần như mọi token đều làm được tới mức đó. Điều thực sự cho bạn biết liệu một mạng có sống sót qua giai đoạn trợ cấp của chính nó hay không, chính là nửa còn lại: phía doanh thu gặp phía phát thải tại một thời điểm cụ thể. Việc thiếu vắng điều đó không có nghĩa là Babylon không có mô hình nội bộ cho vấn đề này; các đội thường tính ra các con số này riêng trước khi cam kết công khai các dự phóng. Nhưng từ góc nhìn của tôi khi cố đánh giá nó, sự im lặng về nửa đó vẫn mang một ý nghĩa tương tự, dù câu trả lời có khiến người ta yên tâm hay khiến người ta lo lắng. Tự phê bình: Tôi bước vào với kỳ vọng sẽ hoặc xác nhận hoặc bác bỏ mối lo của mình bằng các con số thực. Kết quả là tôi không có được điều nào—chỉ có thêm xác nhận rằng con số đó vẫn chưa được công bố. Đây là một phát hiện khác, yếu hơn so với điều tôi định tìm, và tôi thà nói thẳng như vậy còn hơn cố kéo bảng phát thải thành một kết luận mà nó không đủ sức hỗ trợ. $BABY holders đang thực chất đứng ra bảo lãnh cho quá trình chuyển đổi đó mà không hề được cho xem mô hình cho nó. Tôi muốn điểm giao nhau đó được công bố, ít nhất cũng ở mức ước lượng, trước khi coi mức tham gia hiện tại là bất cứ điều gì hơn ngoài trạng thái đang được trợ cấp bằng phát thải. #baby

Đúng một phần

#baby $BABY @BabylonLabs_io

Sau khi viết về việc giảm phát thải và liệu doanh thu phí có thể bù đắp phần chênh lệch mà nó để lại hay không, tôi bắt đầu tìm các con số thực tế thay vì để mối lo chỉ dừng ở mức trừu tượng. Tôi muốn biết nơi Babylon công bố đường cong phát thải và, lý tưởng nhất, là một số dự phóng về doanh thu dựa trên mức sử dụng so với đường cong đó.

Tôi đã tìm được lịch phát thải mà không gặp mấy khó khăn—các bảng dữ liệu nêu rõ lượng phát hành theo từng kỳ, các tỷ lệ suy giảm, mọi thứ đều được trình bày khá rõ ràng.

Thứ tôi không thể tìm thấy là nửa còn lại của phương trình. Không có gì thể hiện việc đối chiếu lịch phát thải đó với khối lượng vay TBV dự kiến hoặc với doanh thu phí staking, cũng không có mô hình nào cho thấy thời điểm người ta chuyển giao từ phần này sang phần kia. Tôi đã kiểm tra các bài đăng về quản trị, các cập nhật blog, thậm chí tìm kiếm mọi bình luận của đội ngũ về chủ đề này. Có rất nhiều thảo luận về tăng trưởng và mức độ áp dụng, nhưng không có gì được đóng khung theo kiểu: "đây là dữ liệu mức sử dụng cần phải như thế nào cho tới khi phát thải giảm xuống còn X".

Điểm kỹ thuật: công bố lịch phát thải là một mốc minh bạch cơ bản—gần như mọi token đều làm được tới mức đó. Điều thực sự cho bạn biết liệu một mạng có sống sót qua giai đoạn trợ cấp của chính nó hay không, chính là nửa còn lại: phía doanh thu gặp phía phát thải tại một thời điểm cụ thể. Việc thiếu vắng điều đó không có nghĩa là Babylon không có mô hình nội bộ cho vấn đề này; các đội thường tính ra các con số này riêng trước khi cam kết công khai các dự phóng. Nhưng từ góc nhìn của tôi khi cố đánh giá nó, sự im lặng về nửa đó vẫn mang một ý nghĩa tương tự, dù câu trả lời có khiến người ta yên tâm hay khiến người ta lo lắng.

Tự phê bình: Tôi bước vào với kỳ vọng sẽ hoặc xác nhận hoặc bác bỏ mối lo của mình bằng các con số thực. Kết quả là tôi không có được điều nào—chỉ có thêm xác nhận rằng con số đó vẫn chưa được công bố. Đây là một phát hiện khác, yếu hơn so với điều tôi định tìm, và tôi thà nói thẳng như vậy còn hơn cố kéo bảng phát thải thành một kết luận mà nó không đủ sức hỗ trợ.

$BABY holders đang thực chất đứng ra bảo lãnh cho quá trình chuyển đổi đó mà không hề được cho xem mô hình cho nó.

Tôi muốn điểm giao nhau đó được công bố, ít nhất cũng ở mức ước lượng, trước khi coi mức tham gia hiện tại là bất cứ điều gì hơn ngoài trạng thái đang được trợ cấp bằng phát thải. #baby

#baby $BABY @babylonlabs_io Sau khi viết về sự tách nhánh trong quản trị giữa Babylon và Aave, tôi quyết định thật sự đi tìm một đề xuất cụ thể, thay vì chỉ mô tả cấu trúc đó về mặt lý thuyết. Tôi tìm diễn đàn quản trị của Aave và xem có gì liên quan đến thị trường BTC—nơi TBV gắn vào hay không. Tôi tìm thấy các thread. Tôi không thấy bất kỳ thứ gì được viết rõ ràng cho người xuất phát từ phía sản phẩm của Babylon. Các đề xuất thì dày đặc: con số về quyền biểu quyết của delegate, các thay đổi tham số được liệt kê dưới dạng phần trăm thô, đánh giá rủi ro kỹ thuật tham chiếu tới các mô hình mà tôi phải tra cứu riêng thì mới hiểu được. Không có gì bị che giấu; diễn đàn là công khai, có đầy đủ mốc thời gian và số lượt bỏ phiếu. Nhưng cũng không có gì chỉ dẫn một người dùng TBV đến với chúng—không có liên kết từ chính giao diện của Babylon, không có thông báo rằng một tham số ảnh hưởng tới tài sản thế chấp BTC thậm chí đang được đưa ra bỏ phiếu. Điểm kỹ thuật: Tôi đã biết lớp quản trị này tồn tại, vì tôi vừa viết về nó, và dù vậy vẫn cần công sức thực sự để tìm ra đúng đề xuất và hiểu nó đã thay đổi điều gì. Đó là sự khác biệt giữa “thông tin là công khai” và “thông tin đến được với những người bị ảnh hưởng.” Quy trình quản trị của Aave đang làm đúng những gì nó được thiết kế để làm cho người dùng Aave. Nó không bao giờ được xây dựng với suy nghĩ về một người gửi BTC xuất phát từ Babylon, và hiện tại chẳng có gì trong dòng chảy đó để bắc qua khoảng trống này. Tự phê bình: Tôi không khẳng định Aave nên thiết kế lại quản trị của mình xoay quanh TBV một cách cụ thể—đó không phải là yêu cầu công bằng đối với một giao thức độc lập. Nhưng tôi vẫn đi tìm với chủ đích, và tôi vẫn cảm thấy mình bị tụt lại phía sau. Một người đã gửi BTC thông qua chính nhận diện của Babylon, mà hoàn toàn không có lý do để biết rằng quản trị của Aave tồn tại, thì thực chất không có con đường nào để đến được với thông tin này. $BABY người dùng bị phơi bày trước các quyết định được đưa ra trong một phòng mà họ không hề biết đó là một “phòng.” Tôi muốn Babylon ít nhất phải hiển thị một thông báo khi các đề xuất quản trị của Aave liên quan được đưa vào hoạt động—thậm chí chỉ cần một liên kết—thay vì để người dùng phải loay hoay tự tình cờ tìm ra như tôi đã làm. ⚠️ Không phải lời khuyên tài chính. DYOR.

Đã xác minh

#baby $BABY @BabylonLabs_io

Sau khi viết về sự tách nhánh trong quản trị giữa Babylon và Aave, tôi quyết định thật sự đi tìm một đề xuất cụ thể, thay vì chỉ mô tả cấu trúc đó về mặt lý thuyết. Tôi tìm diễn đàn quản trị của Aave và xem có gì liên quan đến thị trường BTC—nơi TBV gắn vào hay không.

Tôi tìm thấy các thread. Tôi không thấy bất kỳ thứ gì được viết rõ ràng cho người xuất phát từ phía sản phẩm của Babylon.

Các đề xuất thì dày đặc: con số về quyền biểu quyết của delegate, các thay đổi tham số được liệt kê dưới dạng phần trăm thô, đánh giá rủi ro kỹ thuật tham chiếu tới các mô hình mà tôi phải tra cứu riêng thì mới hiểu được. Không có gì bị che giấu; diễn đàn là công khai, có đầy đủ mốc thời gian và số lượt bỏ phiếu. Nhưng cũng không có gì chỉ dẫn một người dùng TBV đến với chúng—không có liên kết từ chính giao diện của Babylon, không có thông báo rằng một tham số ảnh hưởng tới tài sản thế chấp BTC thậm chí đang được đưa ra bỏ phiếu.

Điểm kỹ thuật: Tôi đã biết lớp quản trị này tồn tại, vì tôi vừa viết về nó, và dù vậy vẫn cần công sức thực sự để tìm ra đúng đề xuất và hiểu nó đã thay đổi điều gì. Đó là sự khác biệt giữa “thông tin là công khai” và “thông tin đến được với những người bị ảnh hưởng.” Quy trình quản trị của Aave đang làm đúng những gì nó được thiết kế để làm cho người dùng Aave. Nó không bao giờ được xây dựng với suy nghĩ về một người gửi BTC xuất phát từ Babylon, và hiện tại chẳng có gì trong dòng chảy đó để bắc qua khoảng trống này.

Tự phê bình: Tôi không khẳng định Aave nên thiết kế lại quản trị của mình xoay quanh TBV một cách cụ thể—đó không phải là yêu cầu công bằng đối với một giao thức độc lập. Nhưng tôi vẫn đi tìm với chủ đích, và tôi vẫn cảm thấy mình bị tụt lại phía sau. Một người đã gửi BTC thông qua chính nhận diện của Babylon, mà hoàn toàn không có lý do để biết rằng quản trị của Aave tồn tại, thì thực chất không có con đường nào để đến được với thông tin này.

$BABY người dùng bị phơi bày trước các quyết định được đưa ra trong một phòng mà họ không hề biết đó là một “phòng.”

Tôi muốn Babylon ít nhất phải hiển thị một thông báo khi các đề xuất quản trị của Aave liên quan được đưa vào hoạt động—thậm chí chỉ cần một liên kết—thay vì để người dùng phải loay hoay tự tình cờ tìm ra như tôi đã làm.

⚠️ Không phải lời khuyên tài chính. DYOR.

#baby $BABY @babylonlabs_io Tôi đã quyết định thực sự rút một khoản nhỏ thay vì chỉ đọc về cách “unbonding” (gỡ khóa) hoạt động. Tôi bấm rút và kỳ vọng sẽ nhận được xác nhận ngay lập tức hoặc ít nhất là một bộ đếm thời gian rõ ràng. Lúc đầu thì không có gì cả—chỉ hiện một trạng thái “pending” (đang chờ), không hề có đồng hồ hay bộ đếm nào cho tôi biết tình trạng pending sẽ kéo dài bao lâu. Tôi quay lại phần tài liệu khi đang chờ để kiểm tra xem liệu mình có bỏ sót điều gì không. Không bỏ sót gì cả: thời gian unbonding đã được tài liệu ghi rõ, chỉ là nó không được hiển thị ở bất kỳ đâu trong giao diện trong lúc bạn đang chờ trải qua thời gian đó. Tôi hiểu theo mặt lý trí rằng staking “native” trên Bitcoin thì việc thoát không diễn ra tức thì, logic tương tự đằng sau thời gian settlement của TBV. Nhưng việc đọc trước rằng “có thời gian unbonding” và việc ngồi chờ trong một trạng thái pending không xác định với BTC của chính mình là hai trải nghiệm khác nhau: một bên là thông tin, bên kia là nhìn thấy tiền của bạn đang nằm ở đâu đó mà bạn không thể chạm vào hoặc theo dõi đầy đủ. Góc nhìn kỹ thuật: bản thân độ trễ unbonding không phải là vấn đề. Mọi hệ thống staking nghiêm túc đều có nó; đó là một phần khiến việc slashing (cắt phạt) trở nên cưỡng chế ngay từ đầu—bạn không thể trừng phạt hành vi sai phạm nếu tiền có thể thoát ra trước khi phát hiện vi phạm. Khoảng cách nằm ở chỗ: cơ chế là đúng, nhưng giao diện không truyền đạt rõ ràng điều đó trong lúc nó đang diễn ra. Sự im lặng khi chờ khiến người dùng cảm thấy mơ hồ, ngay cả khi quy trình bên dưới đang chạy đúng như thiết kế. Tự phê bình: tôi bước vào với việc đã biết trước cơ chế, vậy mà sự mơ hồ vẫn khiến tôi lo lắng đủ để kiểm tra lại tài liệu giữa quá trình. Nếu ai đó staking lần đầu, thiếu bối cảnh đó, sẽ có ít lý do hơn để tin rằng sự im lặng là bình thường và lại có nhiều lý do hơn để cho rằng có điều gì đó đang sai. $BABY cần những người sẵn sàng khóa BTC trong những khoảng thời gian thực sự, không chỉ tham gia rồi thoát ngay. Cảm giác khi thoát đi như thế nào sẽ quyết định liệu ai đó có làm lại lần nữa hay không. Tôi muốn có một bộ đếm thời gian hiển thị trong giai đoạn unbonding, chứ không phải chỉ một từ “status” ngồi đó không thay đổi. #baby ⚠️ Không phải lời khuyên tài chính. DYOR.

#baby $BABY @BabylonLabs_io

Tôi đã quyết định thực sự rút một khoản nhỏ thay vì chỉ đọc về cách “unbonding” (gỡ khóa) hoạt động. Tôi bấm rút và kỳ vọng sẽ nhận được xác nhận ngay lập tức hoặc ít nhất là một bộ đếm thời gian rõ ràng. Lúc đầu thì không có gì cả—chỉ hiện một trạng thái “pending” (đang chờ), không hề có đồng hồ hay bộ đếm nào cho tôi biết tình trạng pending sẽ kéo dài bao lâu.

Tôi quay lại phần tài liệu khi đang chờ để kiểm tra xem liệu mình có bỏ sót điều gì không.

Không bỏ sót gì cả: thời gian unbonding đã được tài liệu ghi rõ, chỉ là nó không được hiển thị ở bất kỳ đâu trong giao diện trong lúc bạn đang chờ trải qua thời gian đó. Tôi hiểu theo mặt lý trí rằng staking “native” trên Bitcoin thì việc thoát không diễn ra tức thì, logic tương tự đằng sau thời gian settlement của TBV. Nhưng việc đọc trước rằng “có thời gian unbonding” và việc ngồi chờ trong một trạng thái pending không xác định với BTC của chính mình là hai trải nghiệm khác nhau: một bên là thông tin, bên kia là nhìn thấy tiền của bạn đang nằm ở đâu đó mà bạn không thể chạm vào hoặc theo dõi đầy đủ.

Góc nhìn kỹ thuật: bản thân độ trễ unbonding không phải là vấn đề. Mọi hệ thống staking nghiêm túc đều có nó; đó là một phần khiến việc slashing (cắt phạt) trở nên cưỡng chế ngay từ đầu—bạn không thể trừng phạt hành vi sai phạm nếu tiền có thể thoát ra trước khi phát hiện vi phạm. Khoảng cách nằm ở chỗ: cơ chế là đúng, nhưng giao diện không truyền đạt rõ ràng điều đó trong lúc nó đang diễn ra. Sự im lặng khi chờ khiến người dùng cảm thấy mơ hồ, ngay cả khi quy trình bên dưới đang chạy đúng như thiết kế.

Tự phê bình: tôi bước vào với việc đã biết trước cơ chế, vậy mà sự mơ hồ vẫn khiến tôi lo lắng đủ để kiểm tra lại tài liệu giữa quá trình. Nếu ai đó staking lần đầu, thiếu bối cảnh đó, sẽ có ít lý do hơn để tin rằng sự im lặng là bình thường và lại có nhiều lý do hơn để cho rằng có điều gì đó đang sai.

$BABY cần những người sẵn sàng khóa BTC trong những khoảng thời gian thực sự, không chỉ tham gia rồi thoát ngay. Cảm giác khi thoát đi như thế nào sẽ quyết định liệu ai đó có làm lại lần nữa hay không.

Tôi muốn có một bộ đếm thời gian hiển thị trong giai đoạn unbonding, chứ không phải chỉ một từ “status” ngồi đó không thay đổi. #baby

⚠️ Không phải lời khuyên tài chính. DYOR.

#baby $BABY @babylonlabs_io Tôi tự đào lại tài liệu sau khi viết về việc chẳng ai trong một nhóm có thể đồng ý liệu việc slashing (phạt do vi phạm) có đánh vào người ủy thác hay không, thay vì chỉ nêu ra sự lẫn lộn và bỏ đó. Tôi mở tài liệu chính thức trước. Phần về slashing khá ngắn: nó mô tả hành vi bị trừng phạt, như double-signing hoặc equivocation, nhưng không nói rõ ràng trong một câu duy nhất liệu tài sản (stake) của người ủy thác có thực sự bị ảnh hưởng hay không. Sau đó tôi chuyển sang các bài viết kỹ thuật hơn, rồi thẳng vào kênh cộng đồng để hỏi trực tiếp. Câu trả lời tôi nhận được không sai, nhưng cũng không thật sự rõ ràng hoàn toàn, kiểu như "cơ chế được thiết kế để tập trung rủi ro về phía nhà cung cấp", chứ không phải một câu khẳng định phẳng rằng "người ủy thác hoàn toàn an toàn." Tôi đã đọc lại ba lần để đảm bảo mình không hiểu sai ý định. Điểm kỹ thuật: điều khiến tôi chú ý không phải là câu trả lời sai, mà là đáp án đúng nằm rải rác ở nhiều lớp; tài liệu bao phủ một phần, phần giải thích của cộng đồng bổ sung thêm phần khác, và một người dùng bình thường phải tự ghép các mảnh đó lại mới có được bức tranh đầy đủ. Với một cơ chế quyết định liệu bạn có mất BTC hay không, việc phải tự ghép như vậy là một rào cản thực sự, không phải chỉ là bất tiện nhỏ. Tự phê bình: tôi có lợi thế là biết phải tìm ở đâu và có thời gian để đọc lại nhiều lần. Một người ủy thác lần đầu, háo hức bắt đầu kiếm lợi, gần như chắc chắn sẽ không đi qua toàn bộ các bước như tôi vừa làm, và sẽ kết thúc việc ủy thác với cùng mức hiểu biết mơ hồ như ban đầu. $BABY chỉ kéo vào vốn mà thực sự được giữ lại nếu người ủy thác hiểu mình đang mang theo rủi ro gì, chứ không phải nếu họ chỉ vận hành dựa trên cảm giác an toàn. Tôi nghĩ Babylon cần một câu trả lời rõ ràng, dứt khoát đặt ngay tại bước ủy thác, thay vì để người dùng phải tự đi đào tìm như tôi vừa làm.

#baby $BABY @BabylonLabs_io

Tôi tự đào lại tài liệu sau khi viết về việc chẳng ai trong một nhóm có thể đồng ý liệu việc slashing (phạt do vi phạm) có đánh vào người ủy thác hay không, thay vì chỉ nêu ra sự lẫn lộn và bỏ đó.

Tôi mở tài liệu chính thức trước. Phần về slashing khá ngắn: nó mô tả hành vi bị trừng phạt, như double-signing hoặc equivocation, nhưng không nói rõ ràng trong một câu duy nhất liệu tài sản (stake) của người ủy thác có thực sự bị ảnh hưởng hay không. Sau đó tôi chuyển sang các bài viết kỹ thuật hơn, rồi thẳng vào kênh cộng đồng để hỏi trực tiếp.

Câu trả lời tôi nhận được không sai, nhưng cũng không thật sự rõ ràng hoàn toàn, kiểu như "cơ chế được thiết kế để tập trung rủi ro về phía nhà cung cấp", chứ không phải một câu khẳng định phẳng rằng "người ủy thác hoàn toàn an toàn." Tôi đã đọc lại ba lần để đảm bảo mình không hiểu sai ý định.

Điểm kỹ thuật: điều khiến tôi chú ý không phải là câu trả lời sai, mà là đáp án đúng nằm rải rác ở nhiều lớp; tài liệu bao phủ một phần, phần giải thích của cộng đồng bổ sung thêm phần khác, và một người dùng bình thường phải tự ghép các mảnh đó lại mới có được bức tranh đầy đủ. Với một cơ chế quyết định liệu bạn có mất BTC hay không, việc phải tự ghép như vậy là một rào cản thực sự, không phải chỉ là bất tiện nhỏ.

Tự phê bình: tôi có lợi thế là biết phải tìm ở đâu và có thời gian để đọc lại nhiều lần. Một người ủy thác lần đầu, háo hức bắt đầu kiếm lợi, gần như chắc chắn sẽ không đi qua toàn bộ các bước như tôi vừa làm, và sẽ kết thúc việc ủy thác với cùng mức hiểu biết mơ hồ như ban đầu.

$BABY chỉ kéo vào vốn mà thực sự được giữ lại nếu người ủy thác hiểu mình đang mang theo rủi ro gì, chứ không phải nếu họ chỉ vận hành dựa trên cảm giác an toàn.

Tôi nghĩ Babylon cần một câu trả lời rõ ràng, dứt khoát đặt ngay tại bước ủy thác, thay vì để người dùng phải tự đi đào tìm như tôi vừa làm.

#baby $BABY @babylonlabs_io Một người ủy quyền cho một nhà cung cấp tính cuối cùng (finality) cỡ vừa đã hỏi trong một nhóm: “Nếu nhà cung cấp của tôi bị phạt do ký kép (double-signing), thì tôi có mất BTC luôn không, hay chỉ có họ mất?” Ba người trả lời cùng lúc, hai người nói “chỉ có nhà cung cấp,” một người nói “không, cả người ủy quyền nữa.” Không ai trích nguồn, cuộc thảo luận chỉ chuyển sang chủ đề tiếp theo. Chính sự bất đồng đó—tồn tại ngay từ đầu—là vấn đề. Mô hình staking của Babylon hoạt động vì BTC đứng ra “đỡ” các nhà cung cấp tính cuối cùng, những bên có thể bị trừng phạt nếu làm sai. Hành vi gây lỗi chính là việc ký kép hoặc mập mờ/đưa ra nhiều phiên bản (equivocating) đến mức kích hoạt hình phạt. @babylonlabs_io đã thiết kế việc slashing như cơ chế khiến cho sự không trung thực trở nên tốn kém—đúng thứ mà một hệ thống bảo mật phân tán cần. Nhưng việc “chi phí” đó rơi vào chỉ phần stake của chính nhà cung cấp hay còn chạm tới cả phần stake đã được ủy quyền đứng phía sau họ là chi tiết quyết định mức độ ai đó nên thực sự thẩm định kỹ lưỡng người mà họ dự định ủy quyền. Điểm kỹ thuật: đây không phải là một khác biệt nhỏ. Nếu slashing chỉ đánh vào stake tự thân của nhà cung cấp, thì người ủy quyền chỉ đối mặt với bất lợi giới hạn ngoài chi phí cơ hội, và việc chọn một nhà cung cấp nhỏ hơn là rủi ro rất thấp. Nếu stake được ủy quyền cũng được chia sẻ rủi ro, thì mọi quyết định ủy quyền đều mang “rủi ro đuôi” thực sự, và việc tùy tiện ủy quyền cho bất kỳ nhà cung cấp nào mà một người bạn vừa nhắc tới sẽ không còn là bất tiện nhỏ nữa, mà trở thành điều gì đó gần như “due diligence” (thẩm tra cẩn thận). Ba câu trả lời chắc chắn, mâu thuẫn nhau trong cùng một thread cho thấy đây không phải là kiến thức phổ biến ngay cả trong số những người đã đang staking. Tự phản biện: Tôi thà chỉ ra rằng sự bất đồng tồn tại còn hơn là nêu ra một con số mà chính tôi không thể xác minh đầy đủ; điều đó tệ hơn việc thừa nhận sự không chắc chắn. Nhưng việc những người ủy quyền tích cực không thể thống nhất về bất lợi của chính họ là một phát hiện—ngay chính nó. Chào mời staking của $BABY hoàn toàn dựa vào việc mọi người có thể ủy quyền một cách tự tin, mà điều đó đòi hỏi họ phải biết rõ trước tiên mình thực sự đang bị phơi nhiễm tới điều gì. Tôi mong Babylon làm cho mức phơi nhiễm của người ủy quyền với slashing trở nên không thể hiểu nhầm—không chỉ được ghi chú ở đâu đó trong tài liệu kỹ thuật. ⚠️ Không phải lời khuyên tài chính. DYOR.

#baby $BABY @BabylonLabs_io

Một người ủy quyền cho một nhà cung cấp tính cuối cùng (finality) cỡ vừa đã hỏi trong một nhóm: “Nếu nhà cung cấp của tôi bị phạt do ký kép (double-signing), thì tôi có mất BTC luôn không, hay chỉ có họ mất?” Ba người trả lời cùng lúc, hai người nói “chỉ có nhà cung cấp,” một người nói “không, cả người ủy quyền nữa.” Không ai trích nguồn, cuộc thảo luận chỉ chuyển sang chủ đề tiếp theo.

Chính sự bất đồng đó—tồn tại ngay từ đầu—là vấn đề.

Mô hình staking của Babylon hoạt động vì BTC đứng ra “đỡ” các nhà cung cấp tính cuối cùng, những bên có thể bị trừng phạt nếu làm sai. Hành vi gây lỗi chính là việc ký kép hoặc mập mờ/đưa ra nhiều phiên bản (equivocating) đến mức kích hoạt hình phạt. @BabylonLabs_io đã thiết kế việc slashing như cơ chế khiến cho sự không trung thực trở nên tốn kém—đúng thứ mà một hệ thống bảo mật phân tán cần. Nhưng việc “chi phí” đó rơi vào chỉ phần stake của chính nhà cung cấp hay còn chạm tới cả phần stake đã được ủy quyền đứng phía sau họ là chi tiết quyết định mức độ ai đó nên thực sự thẩm định kỹ lưỡng người mà họ dự định ủy quyền.

Điểm kỹ thuật: đây không phải là một khác biệt nhỏ. Nếu slashing chỉ đánh vào stake tự thân của nhà cung cấp, thì người ủy quyền chỉ đối mặt với bất lợi giới hạn ngoài chi phí cơ hội, và việc chọn một nhà cung cấp nhỏ hơn là rủi ro rất thấp. Nếu stake được ủy quyền cũng được chia sẻ rủi ro, thì mọi quyết định ủy quyền đều mang “rủi ro đuôi” thực sự, và việc tùy tiện ủy quyền cho bất kỳ nhà cung cấp nào mà một người bạn vừa nhắc tới sẽ không còn là bất tiện nhỏ nữa, mà trở thành điều gì đó gần như “due diligence” (thẩm tra cẩn thận). Ba câu trả lời chắc chắn, mâu thuẫn nhau trong cùng một thread cho thấy đây không phải là kiến thức phổ biến ngay cả trong số những người đã đang staking.

Tự phản biện: Tôi thà chỉ ra rằng sự bất đồng tồn tại còn hơn là nêu ra một con số mà chính tôi không thể xác minh đầy đủ; điều đó tệ hơn việc thừa nhận sự không chắc chắn. Nhưng việc những người ủy quyền tích cực không thể thống nhất về bất lợi của chính họ là một phát hiện—ngay chính nó.

Chào mời staking của $BABY hoàn toàn dựa vào việc mọi người có thể ủy quyền một cách tự tin, mà điều đó đòi hỏi họ phải biết rõ trước tiên mình thực sự đang bị phơi nhiễm tới điều gì.

Tôi mong Babylon làm cho mức phơi nhiễm của người ủy quyền với slashing trở nên không thể hiểu nhầm—không chỉ được ghi chú ở đâu đó trong tài liệu kỹ thuật.

⚠️ Không phải lời khuyên tài chính. DYOR.

$LAB tạo đáy chưa anh em, mua sổ xố ít đợi pump x3-x5 là đẹp

LAB+0,00%

#baby $BABY @babylonlabs_io Có người trong một nhóm đã hỏi một câu đơn giản sau khi tinh chỉnh một tham số trên thị trường Aave dùng để vay bằng BTC: "Thực sự ai là người đã phê duyệt thay đổi đó?" Một vài người đoán là "Aave governance" (quản trị Aave), vài người khác đoán "Babylon", và có một người chỉ nói "có thể là cả hai, có quan trọng không." Không ai thực sự biết. Tôi nghĩ điều này quan trọng hơn nhiều so với câu "có thể là cả hai". TBV thực ra là hai hệ thống được ghép lại. @babylonlabs_io điều khiển các cơ chế phía Bitcoin, vault (kho lưu trữ), các điều kiện khóa và mở khóa—phần mà mọi người thường chỉ vào như là điểm mấu chốt không cần tin cậy. Nhưng một khi BTC trở thành tài sản thế chấp trong Aave v4, thì các tỷ lệ LTV (loan-to-value), ngưỡng thanh lý, đường cong lãi suất và cấu hình oracle đều nằm dưới quyền quản trị của chính Aave—một token riêng, cử tri riêng, và quy trình hoàn toàn tách biệt. Điểm kỹ thuật: điều này có nghĩa là các tham số rủi ro thực sự quyết định khi nào vị thế của bạn bị thanh lý không phải là thứ Babylon kiểm soát hoặc có thể đơn phương bảo vệ bạn khỏi. Quản trị Aave có thể nâng ngưỡng thanh lý, chỉnh feed oracle, hoặc điều chỉnh mô hình lãi suất thông qua quy trình đề xuất thông thường của họ, và thay đổi đó sẽ tác động trực tiếp lên các vị thế BTC của người dùng TBV mà không cần Babylon là bên đưa ra quyết định. Câu chuyện “lưu ký không cần tin cậy” là hoàn toàn của Babylon. Câu chuyện về tham số rủi ro là của bên hoàn toàn khác, và đa số người dùng trải nghiệm cả hai như thể đó là một sản phẩm. Tự phản biện: tôi không nghĩ đây là một cái bẫy ẩn. Cả hai quy trình quản trị đều công khai và bất cứ ai cũng có thể theo dõi việc đề xuất diễn ra. Nhưng công khai không đồng nghĩa với việc những người đang thực sự sử dụng TBV có thể nhìn thấy—những người này đến thông qua branding của Babylon và không có lý do rõ ràng để theo dõi các diễn đàn quản trị Aave cùng lúc. $BABY có thể tác động đến phía của Babylon trong chuỗi này. Họ không có quyền bỏ phiếu nào ở phía Aave, phía ngày càng quyết định rủi ro thực tế khi nắm giữ một vị thế TBV. Tôi sẽ muốn có một bản đồ rõ ràng hơn là cơ quan quản trị nào sở hữu những chế độ hỏng hóc nào, trước khi cho rằng “nó phi tập trung” tự trả lời được câu hỏi đó.

Đã xác minh

#baby $BABY @BabylonLabs_io

Có người trong một nhóm đã hỏi một câu đơn giản sau khi tinh chỉnh một tham số trên thị trường Aave dùng để vay bằng BTC: "Thực sự ai là người đã phê duyệt thay đổi đó?" Một vài người đoán là "Aave governance" (quản trị Aave), vài người khác đoán "Babylon", và có một người chỉ nói "có thể là cả hai, có quan trọng không." Không ai thực sự biết.

Tôi nghĩ điều này quan trọng hơn nhiều so với câu "có thể là cả hai".

TBV thực ra là hai hệ thống được ghép lại. @BabylonLabs_io điều khiển các cơ chế phía Bitcoin, vault (kho lưu trữ), các điều kiện khóa và mở khóa—phần mà mọi người thường chỉ vào như là điểm mấu chốt không cần tin cậy. Nhưng một khi BTC trở thành tài sản thế chấp trong Aave v4, thì các tỷ lệ LTV (loan-to-value), ngưỡng thanh lý, đường cong lãi suất và cấu hình oracle đều nằm dưới quyền quản trị của chính Aave—một token riêng, cử tri riêng, và quy trình hoàn toàn tách biệt.

Điểm kỹ thuật: điều này có nghĩa là các tham số rủi ro thực sự quyết định khi nào vị thế của bạn bị thanh lý không phải là thứ Babylon kiểm soát hoặc có thể đơn phương bảo vệ bạn khỏi. Quản trị Aave có thể nâng ngưỡng thanh lý, chỉnh feed oracle, hoặc điều chỉnh mô hình lãi suất thông qua quy trình đề xuất thông thường của họ, và thay đổi đó sẽ tác động trực tiếp lên các vị thế BTC của người dùng TBV mà không cần Babylon là bên đưa ra quyết định. Câu chuyện “lưu ký không cần tin cậy” là hoàn toàn của Babylon. Câu chuyện về tham số rủi ro là của bên hoàn toàn khác, và đa số người dùng trải nghiệm cả hai như thể đó là một sản phẩm.

Tự phản biện: tôi không nghĩ đây là một cái bẫy ẩn. Cả hai quy trình quản trị đều công khai và bất cứ ai cũng có thể theo dõi việc đề xuất diễn ra. Nhưng công khai không đồng nghĩa với việc những người đang thực sự sử dụng TBV có thể nhìn thấy—những người này đến thông qua branding của Babylon và không có lý do rõ ràng để theo dõi các diễn đàn quản trị Aave cùng lúc.

$BABY có thể tác động đến phía của Babylon trong chuỗi này. Họ không có quyền bỏ phiếu nào ở phía Aave, phía ngày càng quyết định rủi ro thực tế khi nắm giữ một vị thế TBV.

Tôi sẽ muốn có một bản đồ rõ ràng hơn là cơ quan quản trị nào sở hữu những chế độ hỏng hóc nào, trước khi cho rằng “nó phi tập trung” tự trả lời được câu hỏi đó.

#baby $BABY @babylonlabs_io Cuối tuần vừa rồi tôi tự trải nghiệm luồng TBV, số lượng nhỏ thôi, chỉ để xem nó hoạt động từ đầu đến cuối. Nạp BTC, theo dõi trạng thái bị khóa, rồi vay USDC dựa trên nó. Bước nạp diễn ra mượt mà. Phần khiến tôi dừng lại là lúc xem trạng thái xác nhận vẫn đứng yên lâu hơn so với lúc tôi kỳ vọng nó sẽ chuyển. Tôi cứ làm mới liên tục, nửa mong chờ có một bản cập nhật kiểu EVM diễn ra ngay. Không có. Chỉ là trạng thái vẫn chưa đổi. Khoảng dừng đó chính là cả sản phẩm, nói thật. @babylonlabs_io không hề che giấu rằng tài sản thế chấp “native” của Bitcoin đang vận hành theo nhịp đồng hồ của Bitcoin, không phải theo nhịp của Ethereum, nhưng việc đọc thấy điều đó trong tài liệu và việc trải nghiệm trực tiếp là hai câu chuyện khác nhau. Biết ở mức lý thuyết rằng TBV bỏ qua token được bọc và các bên giám hộ qua cầu là một chuyện. Còn việc nhìn BTC của chính mình bị khóa trong khi USDC bạn đã vay trên Aave v4 đã nằm sẵn trong ví lại khiến sự đánh đổi trở nên “có thật”, thay vì chỉ là một khái niệm. Điểm kỹ thuật: sự bất đối xứng không phải là lỗi; đó là chi phí thật của việc loại bỏ niềm tin giám hộ. Một cây cầu cho bạn tốc độ vì một bên giám hộ đang thực hiện lời hứa thay bạn. TBV từ bỏ lời hứa đó, và nhịp độ thanh toán của chính Bitcoin sẽ là thứ bạn nhận lại để đổi lấy. Không ai nói dối về cơ chế, nhưng cảm nhận về sự đánh đổi đó chỉ xuất hiện khi bạn thật sự dùng nó, chứ không phải khi bạn mới chỉ đọc về nó. Tự phản biện: tôi bước vào với kỳ vọng câu chuyện về “giám hộ” sẽ là điểm nhấn, nhưng khi ra thì tôi lại nghĩ câu chuyện về “thời gian” mới là thứ người dùng cảm nhận đầu tiên. Tài liệu giải thích các giả định về niềm tin. Chúng không thực sự giải thích cảm giác khi nhìn một thanh trạng thái không nhúc nhích. Pitch của $BABY đặt cược rằng mọi người chấp nhận sự kiên nhẫn như cái giá để loại bỏ một bên giám hộ—thực tế còn khó bán hơn nhiều so với cách nó được trình bày trên giấy. Tôi muốn thông điệp được xây nhiều hơn xung quanh việc “dùng nó thì thật sự cảm thấy như thế nào”, chứ không chỉ là nó “loại bỏ” điều gì.

#baby $BABY @BabylonLabs_io

Cuối tuần vừa rồi tôi tự trải nghiệm luồng TBV, số lượng nhỏ thôi, chỉ để xem nó hoạt động từ đầu đến cuối. Nạp BTC, theo dõi trạng thái bị khóa, rồi vay USDC dựa trên nó. Bước nạp diễn ra mượt mà. Phần khiến tôi dừng lại là lúc xem trạng thái xác nhận vẫn đứng yên lâu hơn so với lúc tôi kỳ vọng nó sẽ chuyển.

Tôi cứ làm mới liên tục, nửa mong chờ có một bản cập nhật kiểu EVM diễn ra ngay. Không có. Chỉ là trạng thái vẫn chưa đổi.

Khoảng dừng đó chính là cả sản phẩm, nói thật. @BabylonLabs_io không hề che giấu rằng tài sản thế chấp “native” của Bitcoin đang vận hành theo nhịp đồng hồ của Bitcoin, không phải theo nhịp của Ethereum, nhưng việc đọc thấy điều đó trong tài liệu và việc trải nghiệm trực tiếp là hai câu chuyện khác nhau. Biết ở mức lý thuyết rằng TBV bỏ qua token được bọc và các bên giám hộ qua cầu là một chuyện. Còn việc nhìn BTC của chính mình bị khóa trong khi USDC bạn đã vay trên Aave v4 đã nằm sẵn trong ví lại khiến sự đánh đổi trở nên “có thật”, thay vì chỉ là một khái niệm.

Điểm kỹ thuật: sự bất đối xứng không phải là lỗi; đó là chi phí thật của việc loại bỏ niềm tin giám hộ. Một cây cầu cho bạn tốc độ vì một bên giám hộ đang thực hiện lời hứa thay bạn. TBV từ bỏ lời hứa đó, và nhịp độ thanh toán của chính Bitcoin sẽ là thứ bạn nhận lại để đổi lấy. Không ai nói dối về cơ chế, nhưng cảm nhận về sự đánh đổi đó chỉ xuất hiện khi bạn thật sự dùng nó, chứ không phải khi bạn mới chỉ đọc về nó.

Tự phản biện: tôi bước vào với kỳ vọng câu chuyện về “giám hộ” sẽ là điểm nhấn, nhưng khi ra thì tôi lại nghĩ câu chuyện về “thời gian” mới là thứ người dùng cảm nhận đầu tiên. Tài liệu giải thích các giả định về niềm tin. Chúng không thực sự giải thích cảm giác khi nhìn một thanh trạng thái không nhúc nhích.

Pitch của $BABY đặt cược rằng mọi người chấp nhận sự kiên nhẫn như cái giá để loại bỏ một bên giám hộ—thực tế còn khó bán hơn nhiều so với cách nó được trình bày trên giấy.

Tôi muốn thông điệp được xây nhiều hơn xung quanh việc “dùng nó thì thật sự cảm thấy như thế nào”, chứ không chỉ là nó “loại bỏ” điều gì.

Đúng một phần

#baby $BABY @babylonlabs_io Có người đã hỏi trong một Discord Babylon: "Nếu nhà cung cấp tính cuối cùng của tôi hoạt động không đúng, điều đó có ảnh hưởng đến cả vault TBV của tôi không, hay staking và vault là những hệ thống riêng biệt?" Một mod đã trả lời "các sản phẩm khác nhau" và dừng ở đó. Tôi không nghĩ câu trả lời đó sai, nhưng tôi cũng không nghĩ nó đầy đủ. Phía staking của Babylon và TBV được tiếp thị như hai thứ khác nhau: một bên cho phép BTC bảo đảm các chuỗi khác thông qua các nhà cung cấp tính cuối cùng, bên còn lại cho phép BTC vay mượn dựa trên chính nó thông qua Aave v4. @babylonlabs_io đã xây dựng chúng như hai sản phẩm tách biệt, nhưng rốt cuộc cả hai đều dựa trên cùng một lớp nền: Bitcoin script, cùng timelock và cơ chế covenant giúp BTC có thể di chuyển mà không cần người giám hộ (custodian). Điểm kỹ thuật: thuộc tính "không cần tin cậy" trong cả hai sản phẩm đến từ cùng một nguồn—các điều kiện tự thực thi được thực thi trên Bitcoin, thay vì một bên thứ ba đáng tin cậy thực thi chúng. Bảo mật staking phụ thuộc vào việc các nhà cung cấp tính cuối cùng hành xử trung thực và đủ phi tập trung, điều mà tôi đã viết trước đây. Logic mở khóa và thanh toán của TBV phụ thuộc vào cùng lớp scripting gốc của Bitcoin hoạt động đúng và đang được triển khai. Chúng là hai ứng dụng tách biệt, nhưng không phải là những giả định tin cậy tách biệt; chúng dùng chung cùng một nền tảng cho hai mục đích khác nhau. Tự phản biện: điều này không có nghĩa là một vấn đề trong staking tự động làm hỏng TBV, hoặc ngược lại—hai sản phẩm không chia sẻ trạng thái (state). Nhưng nó có nghĩa là việc coi "rủi ro staking" và "rủi ro vault" là hoàn toàn không liên quan, như câu trả lời của mod đã ngụ ý, là đang vẽ một ranh giới mang tính tiếp thị sản phẩm hơn là phản ánh đúng mặt kỹ thuật. $BABY nằm ở cả hai sản phẩm như một lớp bảo mật và khuyến khích (incentive), đó chính là lý do nền tảng dùng chung quan trọng hơn việc chỉ có tên thương hiệu dùng chung. Tôi muốn Babylon nêu rõ ràng: những chế độ hỏng (failure modes) nào thực sự được cô lập giữa staking và TBV, và những chế độ nào bắt nguồn từ cùng một cơ chế nền tảng.

#baby $BABY @BabylonLabs_io

Có người đã hỏi trong một Discord Babylon: "Nếu nhà cung cấp tính cuối cùng của tôi hoạt động không đúng, điều đó có ảnh hưởng đến cả vault TBV của tôi không, hay staking và vault là những hệ thống riêng biệt?" Một mod đã trả lời "các sản phẩm khác nhau" và dừng ở đó.

Tôi không nghĩ câu trả lời đó sai, nhưng tôi cũng không nghĩ nó đầy đủ.

Phía staking của Babylon và TBV được tiếp thị như hai thứ khác nhau: một bên cho phép BTC bảo đảm các chuỗi khác thông qua các nhà cung cấp tính cuối cùng, bên còn lại cho phép BTC vay mượn dựa trên chính nó thông qua Aave v4. @BabylonLabs_io đã xây dựng chúng như hai sản phẩm tách biệt, nhưng rốt cuộc cả hai đều dựa trên cùng một lớp nền: Bitcoin script, cùng timelock và cơ chế covenant giúp BTC có thể di chuyển mà không cần người giám hộ (custodian).

Điểm kỹ thuật: thuộc tính "không cần tin cậy" trong cả hai sản phẩm đến từ cùng một nguồn—các điều kiện tự thực thi được thực thi trên Bitcoin, thay vì một bên thứ ba đáng tin cậy thực thi chúng. Bảo mật staking phụ thuộc vào việc các nhà cung cấp tính cuối cùng hành xử trung thực và đủ phi tập trung, điều mà tôi đã viết trước đây. Logic mở khóa và thanh toán của TBV phụ thuộc vào cùng lớp scripting gốc của Bitcoin hoạt động đúng và đang được triển khai. Chúng là hai ứng dụng tách biệt, nhưng không phải là những giả định tin cậy tách biệt; chúng dùng chung cùng một nền tảng cho hai mục đích khác nhau.

Tự phản biện: điều này không có nghĩa là một vấn đề trong staking tự động làm hỏng TBV, hoặc ngược lại—hai sản phẩm không chia sẻ trạng thái (state). Nhưng nó có nghĩa là việc coi "rủi ro staking" và "rủi ro vault" là hoàn toàn không liên quan, như câu trả lời của mod đã ngụ ý, là đang vẽ một ranh giới mang tính tiếp thị sản phẩm hơn là phản ánh đúng mặt kỹ thuật.

$BABY nằm ở cả hai sản phẩm như một lớp bảo mật và khuyến khích (incentive), đó chính là lý do nền tảng dùng chung quan trọng hơn việc chỉ có tên thương hiệu dùng chung.

Tôi muốn Babylon nêu rõ ràng: những chế độ hỏng (failure modes) nào thực sự được cô lập giữa staking và TBV, và những chế độ nào bắt nguồn từ cùng một cơ chế nền tảng.

#baby $BABY @babylonlabs_io Trong cây nến đỏ sắc nhọn trước đó, có người trong một nhóm giao dịch đã hỏi: "Tài sản thế chấp BTC của tôi trên TBV, nếu bị thanh lý thì thực sự mất bao lâu để được khớp?" Không ai trả lời thẳng. Có người chỉ nói "chắc ổn, Aave thanh lý nhanh," rồi cuộc thảo luận chuyển sang chủ đề khác. Câu trả lời đó lại nói về nhầm chuỗi. Thanh lý trên Aave v4 diễn ra nhanh vì Ethereum nhanh: có block mỗi 12 giây, các bên thanh lý cạnh tranh để đóng vị thế đang âm gần như ngay lập tức. Đây là bức tranh mà ai cũng hình dung khi nghĩ về rủi ro TBV. Nhưng tài sản thế chấp đang bị thanh lý lại là native BTC, nằm dưới cơ chế vault chịu điều kiện do Bitcoin cưỡng chế thông qua cơ chế của @BabylonLabs_io, chứ không phải một tài sản kiểu EVM có thể di chuyển theo tốc độ EVM. Điểm kỹ thuật: một sự kiện thanh lý thực chất là hai chiếc đồng hồ chạy song song. Phía nợ trên Aave có thể được đánh dấu và kích hoạt trong vài giây. Phía tài sản thế chấp, tức việc mở khóa hoặc chuyển BTC thực sự ra khỏi một vault, vẫn tuân theo nhịp xác toán riêng của Bitcoin — khoảng mười phút cho mỗi block, và dài hơn nếu tính đến độ sâu xác nhận để đảm bảo an toàn. Ở thị trường bình lặng, khoảng trống này không ai thấy, giống như một sai số làm tròn mà chẳng ai để ý. Nhưng trong một cú sập nhanh, chính khoảng trống đó là nơi có thể lộ ra trượt giá, nợ xấu, hoặc việc một người thanh lý chịu lỗ khi ăn phần thiệt hại, vì thời điểm mà phía nợ phản ứng không trùng với thời điểm mà phía BTC thực sự được xác toán. Tự phản biện: điều này không phải là một khiếm khuyết riêng của TBV. Mọi hệ thống thế chấp xuyên miền đều thừa hưởng phần nào thời gian xác toán chậm hơn của một chuỗi nào đó. Nhưng marketing kiểu "trustless" thường mô tả cam kết giám hộ và im lặng về sự không khớp thời gian, và chính thời gian mới là thứ gãy đầu tiên khi chịu áp lực — không phải giám hộ. Mô hình bảo mật staking của $BABY được xây dựng dựa trên các giả định về finality của Bitcoin, nên chính sự kiên nhẫn khiến Babylon an toàn cũng là sự kiên nhẫn làm cho việc thanh lý nhanh trở nên gượng gạo. Mình muốn xem Babylon có xây dựng bộ đệm nào (nếu có) cho khoảng chênh đó trước khi nó bị kiểm nghiệm bằng khối lượng thực trong một cú sập thật hay không. #baby ⚠️ Không phải lời khuyên tài chính. DYOR.

#baby $BABY @BabylonLabs_io

Trong cây nến đỏ sắc nhọn trước đó, có người trong một nhóm giao dịch đã hỏi: "Tài sản thế chấp BTC của tôi trên TBV, nếu bị thanh lý thì thực sự mất bao lâu để được khớp?" Không ai trả lời thẳng. Có người chỉ nói "chắc ổn, Aave thanh lý nhanh," rồi cuộc thảo luận chuyển sang chủ đề khác.

Câu trả lời đó lại nói về nhầm chuỗi.

Thanh lý trên Aave v4 diễn ra nhanh vì Ethereum nhanh: có block mỗi 12 giây, các bên thanh lý cạnh tranh để đóng vị thế đang âm gần như ngay lập tức. Đây là bức tranh mà ai cũng hình dung khi nghĩ về rủi ro TBV. Nhưng tài sản thế chấp đang bị thanh lý lại là native BTC, nằm dưới cơ chế vault chịu điều kiện do Bitcoin cưỡng chế thông qua cơ chế của @BabylonLabs_io, chứ không phải một tài sản kiểu EVM có thể di chuyển theo tốc độ EVM.

Điểm kỹ thuật: một sự kiện thanh lý thực chất là hai chiếc đồng hồ chạy song song. Phía nợ trên Aave có thể được đánh dấu và kích hoạt trong vài giây. Phía tài sản thế chấp, tức việc mở khóa hoặc chuyển BTC thực sự ra khỏi một vault, vẫn tuân theo nhịp xác toán riêng của Bitcoin — khoảng mười phút cho mỗi block, và dài hơn nếu tính đến độ sâu xác nhận để đảm bảo an toàn. Ở thị trường bình lặng, khoảng trống này không ai thấy, giống như một sai số làm tròn mà chẳng ai để ý. Nhưng trong một cú sập nhanh, chính khoảng trống đó là nơi có thể lộ ra trượt giá, nợ xấu, hoặc việc một người thanh lý chịu lỗ khi ăn phần thiệt hại, vì thời điểm mà phía nợ phản ứng không trùng với thời điểm mà phía BTC thực sự được xác toán.

Tự phản biện: điều này không phải là một khiếm khuyết riêng của TBV. Mọi hệ thống thế chấp xuyên miền đều thừa hưởng phần nào thời gian xác toán chậm hơn của một chuỗi nào đó. Nhưng marketing kiểu "trustless" thường mô tả cam kết giám hộ và im lặng về sự không khớp thời gian, và chính thời gian mới là thứ gãy đầu tiên khi chịu áp lực — không phải giám hộ.

Mô hình bảo mật staking của $BABY được xây dựng dựa trên các giả định về finality của Bitcoin, nên chính sự kiên nhẫn khiến Babylon an toàn cũng là sự kiên nhẫn làm cho việc thanh lý nhanh trở nên gượng gạo.

Mình muốn xem Babylon có xây dựng bộ đệm nào (nếu có) cho khoảng chênh đó trước khi nó bị kiểm nghiệm bằng khối lượng thực trong một cú sập thật hay không. #baby

⚠️ Không phải lời khuyên tài chính. DYOR.