Anna-汤圆

🐝 Ong mật nhỏ — Phát hành Meme công bằng

Đa số người chơi Meme thì sợ cái gì chứ?
Sợ bên nắm lỗng thao túng khống chế giá, sợ đạp giá, sợ bị giữ chốt cuối cùng.

Cách giải của Ong mật nhỏ: khóa chặt 80% số lượng, để mọi người cùng mua ra từ đáy/“pool”.
Bạn không mua được giai đoạn pre-sale, thì tôi cũng không mua được.
Công bằng, đơn giản đến vậy.

📌 Ba lớp logic nền tảng

① Bộ phát bên thứ ba phát hành
Pool an toàn, phía dự án không thể chạm vào, không ai có thể gian lận

② 300+ cộng đồng liên kết khởi xướng, khóa chặt 80% số lượng
Sự tham gia của cộng đồng được mua công bằng hoàn toàn từ pool
Không có phần giữ lại, không có hộp đen, không có “phần đội ngũ”

③ Mô hình cộng đồng nhận 80% số lượng
Công bằng, minh bạch, dựa vào tham gia để lấy được, không dựa vào quan hệ

⚡ Nút khai thiên · Giới hạn 1000 chỗ

Giá: 300 USD/phần
Số lượng: 1000 chỗ, hết là dừng
Lợi thế cốt lõi: mua sớm thì có nhiều币 hơn

Quyền lợi của nút:
1. Năng lực tính toán nút gấp 3 lần (cao hơn 1.2 lần so với bản上线)
2. Trượt giá 2% chia cổ tức vĩnh viễn
3. Chia sẻ 20 nút → lên cấp đại cộng đồng (tối đa 50 chỗ, hưởng 2% trượt giá chia cổ tức)

💰 Mô hình cộng đồng: rơi cũng không sợ, tăng thì càng lời

▸ Vào: từ 100 USD
▸ Giải phóng: mỗi ngày 3%, 60 ngày nhận đủ 1.8 lần Ong mật nhỏ
▸ Cốt lõi: tiêu chuẩn vàng — không xem sắc mặt giá币

Giảm rồi? Vẫn giải phóng, yên tâm nắm giữ
Tăng rồi? Lợi nhuận năng lực tính toán cứ thế bay lên
Dọc hay ngang đều có đường—đây mới là mô hình mà người ta cầm được

🔄 Động cơ giảm phát: càng giao dịch,币 càng ít

Trượt giá giao dịch: mua 3% + bán 3% = tổng 6%
→ 4% chia cho nút và cộng đồng
→ 2% đốt/xóa vĩnh viễn vô hạn

Mỗi giao dịch đều làm giảm lượng lưu thông.
Tự bạn suy ngẫm.

Người khác còn đang vẽ bánh, Ong mật nhỏ thì khóa chặt cái bánh đó.

🐝 Đếm ngược nút khai thiên, hãy theo dõi ➡️ @Seven七七 @小蜜蜂官方

Thị trường tăng điên cuồng quá rồi, còn tôi thì lại nghĩ: sau này ai sẽ có tư cách xem được vị thế của bạn?

Những ngày này, thị trường tăng thật sự “phát điên”. Trên vòng tròn bạn bè đâu đâu cũng thấy “cất cánh rồi”, “thị trường bò đến rồi”.
Nhưng dạo gần đây tôi lại nghiên cứu Dusk, và ngược lại vẫn luôn trăn trở một câu hỏi rất thực tế:

Nếu trong tương lai cổ phiếu, trái phiếu, RWA thực sự được chuyển lên chuỗi với quy mô lớn, liệu vị thế của tôi, giá trị giao dịch của tôi, đối tác giao dịch của tôi… cũng phải giống như nhiều chain công khai hiện nay, “lộ trần” cho cả thế giới xem sao?
Tôi nghĩ các tổ chức tài chính có lẽ sẽ không chấp nhận.

Vì vậy, khi tôi xem lại Dusk, thứ thực sự khiến tôi thấy sáng mắt không chỉ đơn giản là “nó dùng ZK”.

Phoenix của Dusk sử dụng mô hình giao dịch ẩn danh, thông qua chứng minh không kiến thức để mạng lưới xác minh rằng giao dịch là hợp lệ, đồng thời cố gắng không lộ các thông tin giao dịch nhạy cảm.

Điểm thú vị phía sau là một “combo” gồm: JubJub, Poseidon, cấu trúc Merkle, cùng với hệ thống chứng minh PLONK.
Nó không chỉ giải quyết chuyện “giữ dữ liệu không công khai” đơn giản, mà là:

Dữ liệu không được công khai, liệu tôi có còn thể chứng minh rằng bạn được quyền dùng số tiền này, rằng giao dịch không có gian lận, và việc chuyển trạng thái là hợp lệ không?

Hơn nữa, Dusk không biến sự riêng tư thành kiểu “ai cũng không xem được”.
Khi cần các cơ quan quản lý, kiểm toán hoặc tổ chức được ủy quyền xác minh, có thể thực hiện công bố chọn lọc thông qua viewing key.

Tôi nghĩ đây mới giống với sự riêng tư mà tài chính thực sự cần:
Không phải để trốn đi, mà là để bạn tự quyết định lúc nào, và chứng minh cho ai những gì.

Điều thú vị hơn là, bản nâng cấp Aegis của Dusk năm nay đã bật xác thực PLONK V3. Vì vậy

Đây không phải là khái niệm trong whitepaper, mà là đang tiếp tục được triển khai xuống tầng giao thức.

Nếu RWA trong tương lai thật sự cần được đưa lên chuỗi với quy mô lớn, thì tôi ngược lại nghĩ hướng đi “có thể kiểm chứng nhưng không lộ trần” này đáng để theo dõi lâu dài.

Bạn nghĩ rằng khi đưa tài sản tài chính lên chuỗi, mô hình riêng tư nào hợp lý hơn?

#dusk $DUSK @Dusk

ok

Nếu sau khi tài sản số được “lên chuỗi” trong lĩnh vực tài chính, mà mọi người đều có thể nhìn thấy, thì bạn còn dám mua RWA không?

Sau khi tham gia chương trình dành cho nhà sáng tạo của Binance lần này, gần đây mình đã quay lại đọc kỹ lại whitepaper và kiến trúc kỹ thuật của Dusk. Thật ra, điều thú vị nhất ở nó không nằm ở cụm từ “chuỗi quyền riêng tư”.

Mà là ở chỗ nó không hiểu quyền riêng tư theo kiểu “giấu tất cả”.

Thiết kế của Dusk rất thực tế: Moonlight phụ trách các giao dịch công khai, còn Phoenix phụ trách các giao dịch riêng tư. Phoenix dùng ZK để chứng minh giao dịch là hợp lệ, nhưng không công khai trực tiếp các thông tin nhạy cảm như số tiền hay các bên tham gia giao dịch cho tất cả mọi người; nếu cơ quan quản lý, kiểm toán hoặc một tổ chức cụ thể nào đó cần, vẫn có thể thực hiện công bố chọn lọc thông qua viewing key.

Điều này thực ra rất giống với thế giới tài chính thực.

Ngân hàng sẽ không dán số dư tài khoản của bạn lên đường phố, nhưng cũng không thể từ chối việc cơ quan quản lý được xem.

Vì vậy, mình nghĩ Dusk thực sự muốn giải quyết không phải là “làm sao để blockchain ẩn danh hơn”, mà là một vấn đề thực tế hơn:

Làm sao khi tài sản được đưa lên chuỗi, vừa có quyền riêng tư, vừa tuân thủ quy định?

Và đây có lẽ lại chính là “cánh cửa” mà RWA thực sự triển khai không thể né tránh.

Nếu là bạn, bạn đánh giá cao lựa chọn nào hơn?

#dusk $DUSK @Dusk

Mình gần đây đã lật các tài liệu kỹ thuật của Dusk, có một chi tiết khiến mình khá để tâm:
Thực hiện tham chiếu của Rusk—vì sao lại “đồng loạt” dùng Rust?
Nhiều người thấy Rust sẽ có phản xạ đầu tiên là “hiệu năng cao”“an toàn bộ nhớ”.
Nhưng mình nghĩ điều Dusk thực sự coi trọng có thể không chỉ là hai chữ đó.
Vì Rusk không phải viết một ứng dụng thông thường; bên trong vừa chạy cơ chế đồng thuận, vừa xử lý mật mã và logic song song.
Những thứ này sợ điều gì nhất?
Không phải là chạy chậm, mà là một lỗi bộ nhớ mức thấp, cuối cùng biến thành vấn đề an toàn cho cả hệ thống.
Ownership của Rust và Borrow Checker có thể chặn được một lượng lớn lỗ hổng an toàn bộ nhớ ngay từ giai đoạn biên dịch.
Nhưng cần lưu ý ở đây:
An toàn bộ nhớ ≠ an toàn mật mã.
Rust sẽ không chứng minh cho bạn rằng thuật toán chắc chắn đúng, và cũng không tự động xóa sạch các lỗ hổng về logic trong phần hiện thực mật mã.
Thứ nó thực sự cung cấp là một lớp hàng rào an toàn “ở mức thấp”:
ít nhất giúp nhà phát triển tránh được một nhóm bẫy.
Mình thấy điều này đặc biệt thú vị với Dusk.
Bởi vì thứ Dusk muốn làm không phải một blockchain “trông có vẻ an toàn”, mà là chuỗi hướng đến bối cảnh tài chính—khi đưa quyền riêng tư, tuân thủ và thực thi on-chain vào cùng một hệ.
Trong trường hợp như vậy, việc mã nguồn có thể được kiểm toán hay không, các phụ thuộc có thể được truy vết hay không, hiện thực tầng dưới có thể được bảo trì lâu dài hay không… cuối cùng đều trở thành một phần của sản phẩm.
Cho nên hiện tại mình càng nghĩ rằng:
Rust đối với Dusk không phải là thẩm mỹ kỹ thuật, mà là một chiến lược an toàn.
Tất nhiên, Rust cũng không phải thẻ miễn tử.
Thứ quyết định Rusk có an toàn hay không cuối cùng vẫn là mã nguồn, thiết kế mật mã, quá trình kiểm toán và vận hành thực tế.
Nhưng ít nhất xét từ góc độ lựa chọn kiến trúc, Dusk đi theo một con đường mà mình khá đồng tình:
trước hết, những vấn đề có thể xóa bỏ ở giai đoạn biên dịch thì hãy cố gắng xóa bỏ ngay tại biên dịch.
Nếu bạn là nhà phát triển hệ thống tài chính, bạn sẽ coi trọng cái nào hơn?
#dusk $DUSK @Dusk

Mình gần đây đang xem TermMax V2 và có một cảm giác ngày càng rõ ràng:

Nó có lẽ đã không còn giống một Lending Protocol truyền thống nữa.
Trước đây trong DeFi, khi tìm lãi suất cố định, điều khiến mình khó chịu nhất không phải là không vay được, mà là phải tự tìm. @TermMax
Thị trường này lãi suất bao nhiêu?
Trên chain khác thì sao?
Giá trị đơn hàng của Curator có đáng không?
Limit Order có mức giá tốt hơn không?
Thông tin bị rải rác ở nhiều thị trường khác nhau, cuối cùng người dùng tự biến thành “bộ định tuyến thủ công”.
Những gì TermMax V2 đang làm, theo mình, chính là đang giải quyết đúng nỗi đau đó.
Curator Range Orders, Limit Orders và các loại lệnh khác được thống nhất ở lớp thực thi, để người dùng nhìn thấy không phải một đống lệnh, mà là một bản Quote.
Cộng thêm việc gom nhiều chain Market lại để so sánh với nhau.
Điều đó có nghĩa là gì?
Trước đây là mình tự tìm thanh khoản, giờ thì giao thức sẽ giúp mình tìm.
Đó cũng là điều mình thấy thú vị nhất ở TermMax.
Thứ nó thực sự muốn làm có thể không phải là “tạo lại một lending pool khác”, mà là tiến vào hướng Liquidity Router trong cuộc đua lãi suất cố định.
Và thiết kế lãi suất cố định, kỳ hạn cố định ban đầu của nó lại vừa đủ để làm nền tảng tốt cho kiểu định tuyến này: lãi suất có thể so sánh trực tiếp, đồng thời chi phí vốn cũng có thể được khóa trước.
Khi tham gia các sản phẩm dạng này, thứ mình quan tâm nhất không phải là trang web đẹp đến mức nào, mà là nó có thật sự giúp người dùng giảm được một bước hay không. #TermMax
Về điểm này, mình nghĩ V2 đã làm được.

Vì vậy mình lại muốn hỏi mọi người:
Nếu trong tương lai lãi suất cố định on-chain thật sự xuất hiện “sàn/siêu thị lãi suất”, bạn muốn giao thức giúp bạn giải quyết việc nào nhất?

Kho báu mà Dusk đặt cược, có thể căn bản không phải là hai chữ "quyền riêng tư"

Mấy ngày nay tôi đem toàn bộ đống điểm kỹ thuật của Dusk ra trải ra xem lại một lần nữa, rồi chợt nhận ra mình vẫn luôn hiểu sai về định vị của nó @Dusk
//
Ban đầu tôi tưởng Dusk chỉ là thêm một đồng privacy khác, kiểu giấu số dư, giấu địa chỉ, giấu đối tác giao dịch—logic tương tự như bộ khung của Monero. Nhưng khi tôi ghép các mảnh XSC, CITP lại với nhau để nhìn tổng thể, tôi mới thấy thứ nó đang xây dựng thực sự là cả một chuỗi thực thi cho token hóa chứng khoán/RWA—từ đưa tài sản lên chuỗi, công bố tuân thủ, đến thực thi giao dịch; mỗi mắt xích đều đang hướng về phía "được cơ quan quản lý chấp nhận", chứ không phải cố theo đuổi "ẩn danh tuyệt đối" #
//
Tôi thấy thú vị nhất ở khái niệm "tính tương tác bí mật". Trạng thái riêng tư không phải là một hòn đảo cô lập: dữ liệu giấu trên chuỗi phải có thể giao tiếp với các hệ thống tài chính truyền thống bên ngoài, với các chain khác, và vẫn không làm lộ bí mật trong quá trình giao tiếp. Điều này còn khó hơn nhiều so với chuyện chỉ "giấu đi"—giấu là dễ, giấu xong còn phải được kiểm chứng, còn phải tích hợp được với hệ thống bên ngoài, thì mới là bản lĩnh thật sự
//
Tôi tự suy nghĩ rằng, hiện giờ Dusk còn thiếu thứ không phải là công nghệ quyền riêng tư bản thân để được các tổ chức áp dụng quy mô lớn. Thứ thiếu là vòng ngoài—những cái như oracle đáng tin cậy, bộ công cụ có thể vượt qua kiểm toán, và các giao diện khớp với chuẩn mực của tài chính truyền thống. Đây mới là "một dặm cuối cùng" của việc liệu các cơ quan tuân thủ có thực sự dùng được hay không #dusk
//
Sau khi nghĩ thông được điều đó, cách tôi hiểu về Dusk đã hoàn toàn thay đổi. Thứ nó đặt cược không phải "quyền riêng tư" tự thân, mà là "quyền riêng tư như tấm vé để đưa tài sản được quản lý lên chuỗi"—điều này hoàn toàn khác với các privacy coin truyền thống: một bên muốn biến bạn biến mất hoàn toàn, còn bên kia muốn bạn vẫn giữ được quyền riêng tư trong khi vẫn nằm trong vòng quản lý
//
Hỏi một câu: Định vị cốt lõi của Dusk gần với điều gì hơn? $DUSK

Tôi đã đào ra chỗ cất “thông minh” của TermMax V2 ở đâu @TermMax

Mấy ngày nay tôi lục tung ứng dụng của TermMax V2, nói thật lúc đầu không thấy nó có gì đặc biệt cho lắm, cho đến khi tôi phát hiện ra mình đã bỏ sót một việc mà trước giờ lần nào vay mượn cũng phải làm—đó là so sánh giá.
//
Trước đây khi dùng DeFi để vay, trong đầu tôi luôn căng một sợi dây: lãi suất của lệnh này có đáng không? Bên cái pool kia có tốt hơn không? Chuyển qua chuyển lại, cuối cùng tự mình biến thành một “người ghép lệnh” làm bằng tay. Ở V2 lần này họ trực tiếp dỡ bỏ tầng rắc rối đó. Các loại lệnh trước đây phân biệt rõ ràng như Curator Range Orders, Limit Orders… được nhét vào cùng một lớp thực thi. Tôi mở App lên và thấy ngay một Quote—còn đống “việc làm so sánh giá” phía sau thì giao thức đã làm xong thay tôi rồi.
//
Điểm tôi cảm nhận rõ nhất là phần cross-chain. Trước đây muốn so sánh cơ hội lãi suất giữa các chain khác nhau, tôi phải mở vài trang rồi qua lại. Còn giờ phía chính thức nói là “one app, every chain, every order”: nhiều thị trường trên các chain khác nhau được bày thẳng cùng nhau. Giao thức còn gom các lệnh đến từ các nguồn khác nhau thành một giao dịch, giúp tôi tìm đường đi tối ưu—tôi không cần tự từng lệnh một đi ghép.
//
Tôi tự mày mò một chút: lần nâng cấp này thứ thực sự “đáng tiền” không phải giao diện có đẹp hay không, mà là dời hai việc phiền phức—“tốn thời gian đi tìm thông tin” và “tự mình thực thi so sánh giá”—ra khỏi người dùng và chuyển nó lên tầng giao thức. Nó giờ không còn giống một pool vay mượn theo nghĩa truyền thống nữa, mà giống như một bộ định tuyến lãi suất on-chain. Thứ bạn cần không phải là pool nào, mà là giá nào tốt nhất, và việc thực thi thuận nhất.
Fixed-rate Liquidity Router, tôi thấy cách gọi này đúng với diện mạo hiện tại của nó hơn là “Lending Protocol”#TermMax
//
Hỏi một câu: TermMax V2 thực sự đã giúp tiết kiệm chi phí gì?

Trong vài ngày qua, tôi mở app TermMax V2 lên chơi thử một vòng. Càng dùng càng thấy rằng trọng điểm của lần nâng cấp này bị rất nhiều người hiểu sai. @TermMax
//
Có lẽ đa số người nghĩ rằng V2 chỉ là giao diện đẹp hơn một chút, thêm vài loại lệnh. Nhưng tôi lục tìm một hồi mới phát hiện: sự thay đổi thật sự lại nằm ở chỗ bạn không nhìn thấy được—nó gom các loại lệnh trước đây vốn rời rạc như Curator Range Orders, Limit Orders vào chung một lớp thực thi. Trước kia bạn phải tự phân biệt xem loại lệnh nào phù hợp với tình huống hiện tại. Còn bây giờ, các khác biệt ấy đã được giao thức “nuốt mất”, trước mặt bạn chỉ có một điểm vào thực thi thống nhất
//
Điều đáng nói nhất theo tôi là thiết kế “Best Execution”. Trước đây khi dùng DeFi để vay mượn, bạn phải tự lần lượt so sánh sổ lệnh, tự tính xem lãi suất nào có lợi hơn—nói thẳng là bạn chính là người ghép lệnh. V2 loại bỏ hẳn bước đó. Bạn mở app lên sẽ thấy một Quote, còn giao thức đã ở phía sau giúp bạn so sánh qua một lượt. Nghe thì đơn giản, nhưng thực chất là chuyển “chi phí tìm kiếm thông tin” từ người dùng sang tầng giao thức
//
Đi xa hơn một chút, phần so sánh thị trường cross-chain cũng khá thú vị
Phía chính thức hiện nói “one app, every chain, every order” — các thị trường trên nhiều chuỗi được bày thẳng ra cùng một chỗ để bạn xem, bạn không cần phải tự mở nhiều trang rồi qua lại để đối chiếu các cơ hội lãi suất ở từng chuỗi. Giao thức cũng sẽ kết hợp các lệnh đến từ nhiều nguồn thành một giao dịch, giúp bạn tìm lộ trình thanh khoản tối ưu, thay vì bắt bạn tự gom từng đơn lẻ một
//
Theo cách tôi hiểu, khi mọi thứ được xếp chồng lên nhau như vậy, TermMax ngày càng không giống một “hồ bơi lending” theo nghĩa truyền thống, mà giống như một bộ định tuyến lãi suất on-chain—thứ người dùng cần từ trước đến nay không phải là “quỹ nào”, mà là “giá tốt nhất, thực thi thuận nhất”. Cảm giác V2 lần này đang đi về đúng hướng đó. #TermMax
Fixed-rate Liquidity Router, định vị này có lẽ còn chính xác hơn cả Lending Protocol

Sự thay đổi cốt lõi của TermMax V2 là gì?

Trong vài ngày qua, tôi lật lại thiết kế địa chỉ tàng hình của Dusk và phát hiện suy nghĩ trước đây của mình quá đơn giản—chỉ “che giấu số tiền” là không đủ. Phân tích trên chuỗi thực sự nhắm vào tính liên kết của địa chỉ: cùng một địa chỉ nhận tiền nhiều lần, rồi lại xuất hiện nhiều lần, thì đối phương vẫn có thể ghép được bức chân dung tài chính của bạn.

//
Trước hết, tôi nói về phần tôi hiểu: địa chỉ dùng một lần này được tạo ra như thế nào.
Dusk dùng cơ chế thỏa thuận khóa kiểu ECDH. Theo cách tôi hiểu, bên thanh toán cầm thông tin địa chỉ công khai của bên nhận, kết hợp với một số ngẫu nhiên, rồi qua phép tính trên đường cong elliptic để dẫn xuất ra một địa chỉ nhận mới cho mỗi lần thanh toán. Mỗi giao dịch trông hoàn toàn khác nhau. “địa chỉ chính” của bên nhận thì suốt từ đầu đến cuối không trực tiếp lộ ra trên blockchain. Với tôi, một người ngoài cuộc, những gì tôi thấy chỉ là hàng loạt địa chỉ mới trông như chẳng liên quan gì đến nhau—không thể ghép được chúng lại để nhận ra rằng thực ra tất cả đều thuộc về cùng một người.

//
Vậy phản ứng đầu tiên của tôi lúc đó là: khoản tiền mà bên nhận nhận được rốt cuộc họ tìm lại bằng cách nào?
Cái đó dựa vào view key, tức “khóa xem”. Bên nhận cầm khóa này, quét tất cả các output trên chuỗi, rồi dùng cách nhận diện dựa trên khóa để xác định những note nào được dẫn xuất cho mình. Tôi là người ngoài thì không thể làm bước này vì không có vật liệu khóa riêng tương ứng, nhưng bên nhận thì có thể tự tính ra. Điểm hay của thiết kế này theo tôi là view key còn có thể được ủy quyền riêng cho bên thứ ba (ví dụ bên kiểm toán) để họ chỉ làm quét đọc (read-only), không cần phải giao quyền dùng được các khoản tiền thực sự.

//
Tôi đem bộ này so với phương án classic về stealth address (chẳng hạn bộ của CryptoNote) và thấy rằng hệ của Dusk không tồn tại đơn lẻ. Nó cần “khớp” với toàn bộ sổ cái zk. Sau khi địa chỉ dùng một lần được dẫn xuất, tài sản tương ứng phải được đóng gói vào một note. Trong note có kèm cam kết giá trị. Khi chi tiêu, lại phải sinh ra nullifier tương ứng để chống chi tiêu kép (double spend).
Tôi hiểu rằng phần che giấu địa chỉ giải quyết bài toán “không nhìn ra tiền đi đâu”, còn cam kết và nullifier giải quyết “không nhìn ra có bao nhiêu tiền và đã chi chưa”. Ba lớp này cần khớp và liên kết đồng bộ với nhau thì quyền riêng tư mới thực sự hoàn chỉnh; thiếu một mắt xích là sẽ bị lộ.

@Dusk #dusk $DUSK @Dusk
View key có tác dụng gì?

🌙 Đêm đặc biệt Thất Tịch｜Tắng Viên mời bạn cùng đón Thất Tịch

Vòng 27 của trò chơi “Shelly” sắp được khởi động!🔥

📅 Bắt đầu chính thức lúc 12:00 ngày 19 tháng 8
💰 Cộng đồng đã bơm 100.000 giải thưởng vào quỹ đáy Shelly
🎁 Địa chỉ tham gia vòng này, ngoài ra còn nhận thêm ưu đãi 20 Shelly dưới dạng airdrop
⏰ Thời gian nhận hợp lệ: đến 22:00 ngày 20 tháng 8

Tối nay livestream, Tắng Viên sẽ đồng hành cùng mọi người để có một mùa Thất Tịch thật khác ❤️

Buổi livestream lần này xoay quanh Lễ Thất Tịch × trò chơi Shelly,

Trò chơi diễn ra thế nào, nhận phúc lợi ra sao,

và hơn nữa là các quyền lợi airdrop liên tục trong phòng livestream!

Dù bạn là bạn cũ hay bạn mới đến Quảng trường, đều hoan nghênh cùng tham gia chơi.

Tối nay, gặp nhau ở phòng livestream @Anna-汤圆 !
🎁 Airdrop không ngừng
🔥 Trò chơi không ngừng
🌙 Cùng nhau chơi Thất Tịch!

Cổng vào game: 105906.xyz

#舍利子 #MEME #空投

Nếu coi <0-9>@TermMax <0-9> FT, XT, GT như ba Token độc lập, tôi nghĩ rất dễ càng xem càng rối.
Tôi ngược lại gợi ý hãy nghĩ ngược lại vấn đề:
Một khoản DeFi vay thực chất bao gồm những gì?
Thực ra chỉ là vài phần: số tiền trong tương lai phải trả bao nhiêu, giá trị phần lãi suất trong khoản vay đó, và người vay dùng tài sản nào để thế chấp cùng với toàn bộ mức rủi ro mà vị thế đó gánh chịu.
TermMax làm việc chính là tách những thứ đó ra.
Trước hết, hãy xem FT.
Về bản chất, FT giống như một trái phiếu không lãi suất: mua chiết khấu, đến hạn thì được thanh toán theo mệnh giá. Ví dụ, bạn dùng 90 USDC để mua một FT sẽ được nhận 100 USDC khi đáo hạn—thực chất bạn đang mua một dòng tiền trong tương lai được xác định.
Tiếp theo, hãy xem XT.
Nó không phải đơn giản là một “Token điểm thưởng” mà là thành phần giá trị lãi suất trong cấu trúc vay mượn. Trong cơ chế của TermMax, FT và XT cùng tạo nên mối quan hệ giá trị của một khoản nợ, có thể hiểu mối quan hệ cốt lõi là:
1 FT + 1 XT = 1 debt token
Cuối cùng là GT.
GT thú vị hơn nhiều: nó không phải ERC-20 thông thường mà là ERC-721 NFT.
Bạn có thể hiểu nó như một “container vị thế” ghi lại tài sản thế chấp và khoản nợ, đồng thời phản ánh trạng thái của toàn bộ vị thế đòn bẩy. Trước đây, khi quản lý một vị thế đòn bẩy phức tạp, có thể phải xử lý rất nhiều thông tin—nhưng bây giờ có thể đóng gói toàn bộ vị thế vào một NFT.
Vì vậy, nếu đặt ba thứ này cùng nhìn với nhau thì sẽ rõ ràng hơn:
FT giải quyết “số tiền trong tương lai phải thanh toán bao nhiêu”.
XT mang “giá trị lãi suất trong khoản vay đó”.
GT giải quyết “quản lý tài sản thế chấp và toàn bộ vị thế nợ đó như thế nào”.
Đó cũng là điểm khiến tôi thấy TermMax đáng nghiên cứu.
Nó có thể không chỉ là lãi suất cố định, mà là tách một khoản vay theo nghĩa truyền thống thành dòng tiền được chứng khoán hóa, giá trị phần lãi, và một vị thế NFT có thể được quản lý và chuyển nhượng.
Nói thẳng ra là: tách một khoản vay để nhìn nó theo từng phần.
Nhưng vấn đề là
Khi Token bị tách quá chi tiết như vậy, ai sẽ định giá FT, XT và GT?
Những Token với thời hạn khác nhau, lãi suất khác nhau, rủi ro khác nhau thì làm sao hình thành một mức giá hợp lý?
Câu hỏi này, ngược lại, có thể đáng nghiên cứu hơn cả việc “Token nên được tách như thế nào”.
#termMax
FT của TermMax về bản chất giống cái gì hơn?

Trong mấy ngày nay lại lần nữa lần theo cấu trúc giao dịch của Phoenix. Lần này thì mình tách hẳn một giao dịch ra, xem rốt cuộc những thứ nào có thể nhìn thấy trên chuỗi, và những thứ nào thì không thể nhìn thấy
━━━━━━━━━━━━━━
▎note trong đó rốt cuộc chứa gì
Phoenix là mô hình UTXO, mỗi đơn vị tài sản trên chuỗi được gọi là một “note”. Một note gói ba thứ: một cam kết về số tiền (không phải con số hiển thị rõ ràng, mà là giá trị cam kết đã được mã hoá), một hệ số làm mù (nói thẳng là một “muối” ngẫu nhiên được cộng vào để ngăn ai đó suy đoán số tiền dựa trên va chạm), và một số ngẫu nhiên dùng một lần để đảm bảo mỗi note là duy nhất, không trùng với bất kỳ note nào khác
Ba thứ này ghép lại với nhau, thì trên chuỗi người ta chỉ thấy một mớ dữ liệu mã hoá; cụ thể đã chuyển bao nhiêu tiền, và note này rốt cuộc trị giá bao nhiêu, người ngoài hoàn toàn không thể biết. Nhưng mạng vẫn có thể kiểm chứng rằng các cam kết cộng lại cân bằng thu chi, không cần giải mã bất kỳ con số cụ thể nào
━━━━━━━━━━━━━━
▎Chống double-spend dựa trên nullifier
Một điểm mình thấy khá hay ở thiết kế này là: nó không dựa vào việc “xoá các note cũ” để ngăn chi tiêu lặp lại, mà dựa vào việc công khai một chứng từ tiêu dùng không thể liên kết trở lại note gốc
Khi tiêu hết một note, sẽ tạo ra một nullifier tương ứng. Thứ này được tính ra theo cách xác định (deterministic), nhưng người ngoài nhìn vào nó thì hoàn toàn không thể suy ngược nullifier đó thuộc note nào. Mạng chỉ cần theo dõi “nullifier này đã từng xuất hiện chưa”; nếu đã xuất hiện thì nghĩa là note tương ứng đã bị tiêu rồi. Nếu cùng một note muốn chi tiêu lần thứ hai, nó sẽ tạo ra cùng một nullifier, dẫn tới va chạm với bản ghi đã có—hệ thống lập tức từ chối
Toàn bộ quá trình không hề lộ “ai đã chi tiêu cái gì”; chỉ cần kiểm tra va chạm là xong
━━━━━━━━━━━━━━
▎Băm Poseidon, làm nền cho toàn bộ trạng thái riêng tư
Trạng thái riêng tư phải được lưu trong một cây Merkle để dùng cho bằng chứng thành viên (chứng minh “note này thực sự tồn tại trong cây trạng thái”)
Đưa hàm băm thông thường vào mạch zk để tính sẽ tốn kém rất lớn. Poseidon là thuật toán băm được thiết kế riêng cho zk; cấu trúc của nó khớp hơn với hệ thống chứng minh, nhờ đó giảm đáng kể chi phí tính băm trong mạch. Nếu không có loại băm thân thiện với zk này, việc tạo bằng chứng cho cây trạng thái riêng tư sẽ chậm đến mức không thể dùng
@Dusk $DUSK #dusk
Trong giao dịch Phoenix, cơ chế nào có thể ngăn tài sản ẩn bị double-spend?