胖鸟

Ban đầu khi xem @BabylonLabs_io , tôi cũng đặt trọng tâm vào phần Staking, bởi cách hiểu trực quan nhất của thị trường về Babylon chính là khiến nhiều tài sản hơn tham gia vào an ninh mạng. Nhưng sau đó tôi nhận ra điều thực sự thú vị là: vì sao nó lại thiết kế Checkpoint.

Rất nhiều dự án khi làm cross-chain hoặc kết nối hệ sinh thái thường tập trung vào việc tài sản được chuyển như thế nào, tin nhắn được truyền ra sao. Nhưng sau này tôi phát hiện vấn đề khó thật sự không phải là cách kết nối, mà là nếu trạng thái của một mạng cần được mạng khác công nhận, thì phải dựa vào cái gì để chứng minh rằng việc đó thực sự đã xảy ra?

Trên thực tế, câu hỏi này còn khó hơn chuyện kết nối. Trước đây, nhiều giải pháp sẽ đưa thêm một lớp vai trò xác thực, để một hệ thống nào đó chịu trách nhiệm nói với mọi người rằng trạng thái đó là đúng. Nhưng sau khi làm vậy, điểm tin cậy mới cũng sẽ phát sinh.

Và điểm tôi chú ý ở Checkpoint trong #baby là nó không chọn việc thêm một lớp xác thực mới nữa, mà cố gắng làm cho chính trạng thái trở nên dễ được xác nhận hơn. Trong quá trình đó, Finality Provider chịu trách nhiệm tham gia xác nhận trạng thái, còn EOTS dùng để ràng buộc hành vi của những người tham gia.

Thật ra, đây cũng là điểm tôi thấy $BABY đặc biệt. Nó không đơn thuần tạo ra một cơ chế staking mới, cũng không phải xây dựng một hệ sinh thái khép kín, mà đang cố gắng cung cấp một năng lực nền tảng có thể được nhiều mạng khác nhau sử dụng. Nói đơn giản, nó không chỉ quan tâm ai là người cung cấp an ninh, mà còn quan tâm kết quả an ninh đó được xác minh như thế nào.

Đây là một vấn đề rất quan trọng trong môi trường đa chuỗi tương lai: khi ngày càng nhiều mạng bắt đầu kết nối với nhau, điều thực sự khó có thể không phải là để chúng liên lạc, mà là để chúng có thể lâu dài thiết lập niềm tin. Một mạng hôm nay hoạt động bình thường không có nghĩa là sau này chắc chắn đáng tin. Những trạng thái đã diễn ra trong quá khứ, những ghi chép lịch sử, cũng cần được xác nhận lại.

Tất nhiên, hướng này cuối cùng có chạy được hay không còn cần thời gian kiểm chứng. Điểm khó nhất của các dự án hạ tầng không phải là thiết kế một cơ chế, mà là khiến đủ nhiều người tham gia sẵn sàng sử dụng nó trong thời gian dài.

emm... Tôi nghĩ điểm đáng chú ý ở nó là nó không chỉ giải quyết một vấn đề đơn lẻ: ai sẽ cung cấp an ninh. Mà là đang cố gắng giải quyết câu hỏi rằng khi càng nhiều mạng bắt đầu kết nối với nhau, thì niềm tin giữa chúng nên được thiết lập như thế nào. Có lẽ đây mới là hướng mà Babylon thực sự muốn khám phá.

Thời gian trước, khi xem dữ liệu biến động hệ sinh thái do @BabylonLabs_io công bố, tôi cứ suy nghĩ mãi: vì sao hiện nay rất nhiều chuỗi mới, thứ thực sự khó không phải là phát triển, mà là sau khi lên mainnet làm thế nào để nhanh chóng xây dựng được nền tảng bảo mật đáng tin cậy?

Kể từ khi Babylon ra mắt, ngày càng nhiều mạng PoS bắt đầu quan tâm đến mô hình chia sẻ bảo mật. Tính đến hiện tại, hệ sinh thái Babylon đã kết nối với hàng chục mạng blockchain, quy mô tham gia BTC Staking cũng tiếp tục tăng trưởng, và ngày càng nhiều tài sản bắt đầu bước vào thị trường bảo mật này.

Sự thay đổi đó khiến tôi thấy rất thú vị.

Bởi trước đây, nhiều dự án tập trung vào cách thu hút người dùng và tăng TVL. Nhưng Babylon đi vào một bài toán mới: làm sao để giảm chi phí khi thiết lập một hệ thống bảo mật cho mạng mới.

Khi mới bắt đầu nghiên cứu Babylon, tôi cũng hiểu nó như một giao thức dạng staking. Nhưng sau khi đi sâu vào cơ chế của nó, tôi nhận ra rằng mục tiêu thực sự mà Babylon muốn giải quyết không phải là chỉ đơn giản là tạo thêm một cách tạo lợi nhuận, mà là thay đổi con đường để mạng mới xây dựng bảo mật.

Các mạng PoS truyền thống cần tự nuôi các trình xác thực, tự thiết kế các động lực kinh tế, rồi dần dần tích lũy mức độ an toàn.

Còn Babylon mang đến một giải pháp khác: thông qua cơ chế chia sẻ bảo mật, mạng mới có thể kết nối với năng lực bảo mật do Babylon cung cấp, không cần tự xây dựng từ đầu một hệ thống bảo mật hoàn chỉnh.

Điều khiến tôi đặc biệt quan tâm là lớp Finality Provider. Khi nhắc đến Babylon, nhiều người sẽ tập trung vào bản thân việc staking. Nhưng để năng lực bảo mật truyền tải sang các mạng khác nhau, chính là các vai trò chịu trách nhiệm xác nhận và thẩm định cuối cùng. Chúng kết nối mối quan hệ giữa tài sản, nguồn lực bảo mật và mạng ứng dụng.

Đó cũng là điểm khiến tôi thấy Babylon thú vị.

Nó không chỉ đơn thuần tạo ra một kịch bản ứng dụng mới, mà là đang định nghĩa lại mạng cần gì khi khởi động.

Babylon đang khám phá rằng bản thân “bảo mật” cũng có thể trở thành một dạng cơ sở hạ tầng. Tất nhiên, liệu mô hình chia sẻ bảo mật trong tương lai có hình thành được một hệ sinh thái dài hạn hay không vẫn còn nhiều vấn đề cần quan sát, chẳng hạn như thiết kế động lực cho từng mạng, quy mô người tham gia và tính bền vững lâu dài.

Trong tương lai, cạnh tranh giữa các blockchain có thể không chỉ là xem ai có nhiều người dùng và thanh khoản hơn, mà còn là ai có thể xây dựng nền tảng đáng tin cậy một cách hiệu quả hơn. Có lẽ đó mới là hướng mà Babylon thực sự muốn theo đuổi.
#baby $BABY

Nhiều người cho rằng thứ khó sao chép nhất của BTC chính là tính khan hiếm của nó, nhưng sau một nghiên cứu@BabylonLabs_io gần đây, tôi nhận ra rằng điều thực sự khó thay thế là sự đồng thuận an toàn đã được hình thành trong hơn mười năm vận hành.

Đó cũng là lý do gần đây tôi quan tâm$BABY

Thành thật mà nói, lúc đầu khi nhìn thấy hướng đi “BTC Staking”, tôi không đặc biệt hứng thú. Trong vài năm qua, thị trường đã xuất hiện không ít phương án tạo ra lợi nhuận cho BTC, nhưng nhiều phương án về bản chất chỉ là “đóng gói” BTC thành sản phẩm tài chính mới, khiến người dùng gánh thêm rủi ro mà không thật sự giải phóng giá trị vốn có của Bitcoin.

Điểm khiến Babylon làm tôi thay đổi quan điểm là nó không tập trung vào cách “tiêu thụ” tính thanh khoản của BTC, mà vào cách tận dụng năng lực an toàn mà Bitcoin đã hình thành.

#baby có ý tưởng cốt lõi là thông qua các Trustless Bitcoin Vaults và cơ chế BTC Staking, để người nắm giữ BTC có thể tiếp tục giữ quyền kiểm soát tài sản, đồng thời cung cấp hỗ trợ an toàn cho mạng lưới PoS.

Nói một cách đơn giản, Babylon không yêu cầu người dùng chuyển BTC sang hệ sinh thái khác, hay phụ thuộc vào việc các tổ chức tập trung lưu ký, mà muốn tận dụng thuộc tính an toàn “native” của Bitcoin để BTC trở thành một nền tảng an toàn kết nối với các mạng blockchain khác.

Hướng đi này khiến tôi thấy thú vị, vì nó giải quyết một vấn đề tồn tại lâu dài trong hệ sinh thái PoS. Nhiều blockchain mới nổi không phải là không có công nghệ, cũng không thiếu nhà phát triển, mà vì ở giai đoạn đầu rất khó thiết lập nhanh một hệ thống an toàn đủ mạnh. Số lượng trình xác thực, quy mô đặt cược và chi phí kinh tế đều ảnh hưởng đến khả năng một mạng lưới chống lại tấn công.

Còn Bitcoin đã mất hơn mười năm để chứng minh độ an toàn của mình. Nếu trong tương lai, năng lực an toàn này có thể được nhiều mạng lưới PoS tận dụng hơn, thì vai trò của BTC có thể sẽ thay đổi.

Tất nhiên, tôi không đơn giản nghĩ rằng $BABY nhất định sẽ thành công. Lịch sử Crypto chưa bao giờ thiếu những câu chuyện lớn, nhưng thứ quyết định giá trị của một dự án hạ tầng rốt cuộc vẫn là liệu công nghệ có đáng tin cậy, mô hình an toàn có được kiểm chứng hay không, và hệ sinh thái có thực sự áp dụng hay không.

Trước đây, khi hiểu về BTC, chúng ta thường tập trung nhiều hơn vào tính khan hiếm và giá của nó. Nhưng nếu trong tương lai, năng lực an toàn của Bitcoin có thể phục vụ cho nhiều mạng hơn, thì ranh giới giá trị của BTC có thể sẽ được định nghĩa lại.

Có lẽ trong tương lai, chúng ta không chỉ quan tâm đến Bitcoin vì nó đủ khan hiếm.

Thật sự có người tham gia sao? 1 xu đổi 1 u Alpha, thua đến nỗi mất quần lót rồi còn gì.

Đôi khi tôi nhận ra rằng, thời điểm một công ty dễ gặp sự cố nhất không phải là lúc không ai chịu trách nhiệm, mà là khi tất cả mọi người đều chịu trách nhiệm “một chút”. Bên sản phẩm nghĩ rằng bộ phận R&D đã xác nhận rồi, R&D lại cho rằng vận hành đã phê duyệt, và vận hành thì tin rằng pháp vụ sẽ không có ý kiến. Cuối cùng khi sự việc xảy ra vấn đề, ai cũng đã tham gia, nhưng chẳng ai nói rõ rốt cuộc bước nào đã sai.

Sau đó tôi nhìn thấy @NewtonProtocol một chi tiết thiết kế rất nhỏ, và tôi chợt nghĩ đến việc mình trước giờ vẫn chưa thật sự để ý Authorization Receipt. Tôi tưởng nó chỉ là một chứng từ được tạo ra sau khi thực thi xong, giống như biên bản, nhật ký hay biên lai. Nhưng càng xem sâu, tôi càng thấy vị trí xuất hiện của nó thật kỳ lạ.

Nó không nằm ở phần cuối của quy trình. Thay vào đó, nó xuất hiện cùng với Authorization, Policy và Operator, trở thành một phần của toàn bộ quá trình thực thi. Tôi sau đó đọc lại đoạn đó vài lần, rồi mới nhận ra nhận thức ban đầu của mình đã lệch đi. Trước đây, nhiều hệ thống đều lưu kết quả. Giao dịch thành công, tài sản đã được chuyển đi, trạng thái đã được cập nhật—tất cả đều để lại dấu vết. Nhưng khi thực sự có vấn đề xảy ra, người ta thường lại tiếp tục hỏi: ai đã phê duyệt? Căn cứ theo quy tắc nào? Ở giữa có bước nào bị bỏ qua không? Những thông tin đó, nhiều khi chỉ có thể ghép lại dần dần dựa vào log.

Newton dường như vẫn luôn đang giải quyết đúng vấn đề này. Authorization Receipt không chỉ ghi nhận việc đã thực thi xong. Nó nối liền một lần ủy quyền, Policy tương ứng, Operator thực hiện, và kết quả cuối cùng tạo ra thành một chuỗi hoàn chỉnh. Sau này nếu ai đó nghi ngờ lần thực thi này, hệ thống không cần phải tin lại một nút nào đó từ đầu, cũng không cần hỏi lại bên vận hành; chỉ cần đi theo bản ghi đó để xác minh lại, và vì sao từng bước lại hợp lệ đều có thể tìm được căn cứ tương ứng.

Đến đây, tôi bỗng nhận ra rằng trong Newton, Receipt không giống một tờ biên lai. Nó giống như một chuỗi trách nhiệm của một lần thực thi.

Vì vậy, khi quay lại nhìn Authorization Receipt, tôi nghĩ rằng thứ nó thực sự để lại không phải là một “bản ghi”.
Nó để lại toàn bộ căn cứ của một lần thực thi—từ lúc được ủy quyền, đến khâu phán quyết và hoàn tất. Thứ thực sự có thể được tin tưởng lâu dài, có lẽ không phải là một nút cụ thể hay một nền tảng nào đó, mà chính là bản thân quy trình mà bất kỳ ai cũng có thể tự mình xác minh lại.
#newt $NEWT

Kinh khủng rồi

Gần một tháng nay không nhận airdrop #ALPHA , rốt cuộc có bị cuốn đến mức này rồi à? Tối nay 19:00 mở hộp airdrop 251 điểm, hơi quá rồi đấy

Khó chịu thật, một chu kỳ chỉ ăn được một cái

Có chút do dự là đợi dự án mới tuần sau #tge hay là trước mắt cứ nhận trước

Ước chừng lại sắp có thêm một lô người kiếm được bét nhè

Nếu không có gì bất ngờ, thứ Ba tuần sau sẽ ra mắt dự án TGE đã lâu không thấy

Lần này, #tge dùng quy tắc mới, độ “nóng” thì không phải dạng vừa

Anh em đã sẵn sàng chưa?

Theo mức giá chiết khấu trước giờ mở cửa của $GRVT Whales Market, FDV hiện vào khoảng 350 triệu USD. Tiếp theo theo thông lệ, mình sẽ dùng lời dễ hiểu để phân tích sơ bộ xem dự án này rốt cuộc có “đỡ được” không.

​Xét về mặt cơ bản, @grvt_io thực sự giải quyết được nỗi đau của ngành. Hệ thống One Balance do họ tiên phong giúp tiền ký quỹ không còn là tiền chết nữa; trong lúc mở lệnh giao dịch vẫn có thể đồng thời “nuốt” trọn gói lợi suất tự động lên tới 11% ở lớp nền. Kết hợp câu chuyện lai giữa tốc độ của CEX + việc tự lưu trữ tài sản trên DEX, cộng thêm bối cảnh đội ngũ của Goldman Sachs và Meta, nền tảng cơ bản về lâu dài rất vững.

Nhưng rủi ro “thiên nga đen” chí mạng thì cũng đã bày sẵn ngay trước mắt: lần này phía dự án tăng thẳng tỷ lệ airdrop dành cho cộng đồng từ 20% lên thẳng 28%！Đáng ngại hơn là token TGE trong ngày không bắt buộc khóa, nên nếu 28% lượng token khổng lồ đó vừa xuất hiện là ồ ạt đổ ra thị trường, khả năng đỡ đòn của sàn thứ cấp sẽ là một bài kiểm tra áp lực cực kỳ khắc nghiệt.

Tuy vậy, theo quan điểm cá nhân của mình thì không đến mức “mở cửa là đỉnh”. Bởi phía sau là gói tài nguyên cỡ “tàu sân bay” của hệ sinh thái zkSync. Là kỳ vọng cốt lõi của hệ sinh thái flagship trên zkSync Hyperchain, GRVT không chỉ là một sàn giao dịch; nó còn đóng vai trò là một nút quan trọng ở lớp nền cho dòng chảy thanh khoản và khâu giao nhận dữ liệu của cả hệ sinh thái.

Nếu đợt bán tháo kiểu “lũ bùn đá” ngay làn mở cửa mà được market maker hấp thụ, thì sau đó khi dữ liệu giao dịch thật sự chạy lên, “cái bánh đà” One Balance của nó mới bắt đầu phát huy uy lực. Dòng tiền lớn và các LP dài hạn vì muốn ăn cái lợi suất sinh lời 11% đó, sẽ không ngừng đổ ngược từ mainnet ethereum $ETH vào, tạo thành một “hố đen” hút tiền tự nhiên.

Tóm lại, cơ chế của #grvt thì ổn, nhưng định giá 350 triệu USD trước giờ mở cửa thì rất có khả năng không chịu nổi cú giáng đòn airdrop 28% lượng lớn đạp sàn trong ngắn hạn. Tốt nhất là chờ sổ lệnh ổn định, còn số token trên chuỗi được “rửa” gần xong rồi hãy vào. Mức giá trong đầu mình là dưới $0.2.

Anh em thấy giá trước giờ mở cửa $0.35 giữ được không? Giá vào lệnh mà anh em xem là “bức tường tâm lý” của mình là bao nhiêu? Không ngại thì cùng vào bàn nhé.

Đừng để bị những lời thổi phồng gần đây về ＄GRVT lừa gạt

Thứ này không “thân thiện” với nhà đầu tư lẻ như bạn tưởng.

Trong vài ngày qua, tôi đã đồng bộ tài liệu phát triển chính thức của mã @grvt_io , và khi lật đến phần cấu trúc dữ liệu thanh toán, tôi phát hiện ra hai venue và broker rất ít người bàn đến. Sau khi lần theo đường đi thanh toán ở lớp nền, trong lòng tôi chợt lạnh: mọi người đều chăm chăm nhìn xem họ chơi trò mua bán trên bề mặt thế nào, nhưng lại bỏ qua việc hệ thống ở tầng dưới đã mở ra một kênh RFQ ngoài sàn cho các tổ chức và khách hàng lớn. Nhà đầu tư lẻ khi chơi cùng một loại phái sinh về bản chất sẽ phải chịu một cú “búa tạ” do chênh lệch thông tin.

Tôi nhận thấy trong “gầm” của #grvt , các lệnh mua bán một chiều thông thường đi theo sổ lệnh công khai. Nhưng hễ liên quan đến các tổ hợp quyền chọn phức tạp hoặc giao dịch khối lượng cực lớn, hệ thống sẽ cắt thẳng các luồng tiền lớn đó sang một phiên RFQ hỏi giá chuyên biệt, và thông qua các nhà môi giới hàng đầu như CoinRoutes để ghép lệnh riêng tư ngoài chuỗi.

Điều này có ý nghĩa gì?

Các báo giá lô lớn chất lượng nhất—những mức có thể ép chi phí phòng hộ xuống thấp nhất—thực tế đã bị tổ chức và nhà môi giới chuyên nghiệp “ăn sạch” từ trước ở ngoài chuỗi. Phần sổ lệnh công khai mà nhà đầu tư lẻ nhìn thấy, thực chất chỉ là phần cặn còn lại mà các tổ chức ăn thừa. Bạn bỏ công ghép lệnh long/short trong sổ lệnh công khai không những chênh lệch mua-bán rộng hơn, mà còn phải chịu rủi ro ẩn (Legging Risk) do các “chân” giao dịch tách nhau hoàn tất. Thiết kế khóa quyền định giá phần lô lớn béo bở trong vòng sân nhà môi giới—ngoài sàn—vô hình trung dựng lên một bức tường cao vô hình cho nhà đầu tư lẻ.

Tuy nhiên, nếu gạt sang một bên việc cách ly báo giá đối với nhà đầu tư lẻ, thì ở góc nhìn vĩ mô về khả năng chống chịu rủi ro của cả hệ thống thị trường, kiến trúc tách dòng hoàn toàn giữa giao dịch lô lớn và giao dịch bán lẻ lại là vô cùng khôn ngoan. Các sàn giao dịch truyền thống trên chuỗi sở dĩ hay gặp “đứt gãy thanh khoản” vì toàn bộ lệnh lẻ của nhà đầu tư nhỏ và vị thế lô lớn của tổ chức bị trộn chung vào một cái “bể”. Chỉ cần thị trường bị rửa trôi mạnh, nếu các vị thế nhiều chân của tổ chức (quy mô hàng triệu) bị buộc đóng theo sổ lệnh công khai, thì ngay lập tức sẽ kích hoạt một chuỗi giẫm đạp, kéo theo tất cả lệnh cắt lỗ của nhà đầu tư lẻ cùng lúc mà bùng nổ. Còn GRVT khiến giao dịch lô lớn đi theo tuyến RFQ độc lập ngoài chuỗi; dùng cơ chế nhà môi giới như một “vành đai cách ly” để âm thầm vô hiệu hóa các đầu đạn hủy diệt đó ở ngoài thị trường.

Nó tuy làm giảm một chút cơ hội kiếm lợi nhuận套利 béo bở của nhóm bán lẻ, nhưng đổi lại, toàn bộ hệ thống có độ đàn hồi bảng giá cực kỳ ổn định trong cơn bão—để nhà đầu tư lẻ lúc cần thoát hiểm luôn có thể rút đi kịp thời

Thật sự coi thường tham vọng của @NewtonProtocol . Đêm qua tôi tự đi lật lại “whitepaper” của nó về kiến trúc cross-chain và đồng bộ sức mạnh tính toán, và tôi mới phát hiện ra cái “chiêu” thâm sâu mà nó thực sự muốn giải quyết. Thế mà lại chính là việc dẹp bỏ sự phân mảnh tuân thủ và cuộc khủng hoảng niềm tin trong các cây cầu cross-chain—những thứ khiến thời đại đa chuỗi phải đau đầu nhất.

Trong whitepaper $NEWT có nhắc đến một giao thức đồng bộ “multi-chain compute table” dựa trên chuẩn ELIP-008 của EigenLayer. Cái tên nghe rất “lực” đúng không? Lúc đầu tôi cũng tưởng nó đang lôi danh từ cho oai, nhưng nghĩ kỹ hơn thì tôi thấy nó thực ra đang tháo một nút thắt cực kỳ khó chịu trong tài chính on-chain, thứ mà trước đây gần như không ai giải được: làm sao để các ứng dụng trên những chuỗi khác nhau có thể chia sẻ cùng một “bộ bài an ninh kinh tế” cấp độ Ethereum, cường độ cao.

Bạn nghĩ xem, thế giới đa chuỗi bây giờ bị phân mảnh nghiêm trọng. Một stablecoin hay dự án RWA, nếu muốn phát hành đồng thời trên Ethereum, Base, Arbitrum và Optimism, thì cách làm truyền thống cực kỳ đau đớn. Bạn hoặc phải tự tìm ở mỗi chain một bộ node xác thực tuân thủ riêng, hoặc phải dùng loại cầu cross-chain bên thứ ba quá mong manh—ngày nào cũng thấp thỏm chờ bị hacker “cross-chain đầu độc”. Kết quả là các tổ chức lớn căn bản không dám đổ số tiền khổng lồ lên L2.

Trước đây ai cũng mặc định đây là “khiếm khuyết” không thể khắc phục, nhưng Newton lần này lại trực tiếp dùng mật mã học ở tầng nền để tháo nút thắt đó. Theo logic trong #newt , mạng lưới sức mạnh tính toán phi tập trung của nó chỉ cần đăng ký trên mainnet Ethereum và stake lại trên EigenLayer đúng một lần. Chỉ cần trạng thái của các node trên Ethereum—bao gồm thành viên, trọng số stake, hoặc việc bị phạt tước nếu có hành vi gian lận—thay đổi, thì các node của Newton ở tầng nền sẽ đồng loạt “nhả ra” một bảng sức mạnh tính toán được đóng dấu bằng căn cứ khóa BLS để tạo thành Merkel root.

“Ngầu” nhất là chữ ký (signature) này—chứa sự bảo đảm an ninh kinh tế của hàng chục tỷ node trên mainnet—sẽ được đồng bộ điên cuồng tới toàn bộ các L2 phổ biến thông qua một Relayer hoàn toàn không cần cấp phép. Các smart contract trên chain đích chỉ cần dùng các công thức toán học thuần túy để xác thực chữ ký BLS tổng hợp. Chỉ cần đối soát thành công là bảng trọng số sức mạnh tính toán tại chỗ lập tức được cập nhật đồng bộ.

Tôi xem hiểu được luồng đồng bộ sức mạnh tính toán cross-chain theo ELIP-008 này. Rốt cuộc dự án không hề kể một câu chuyện “tuân thủ” hoành tráng. Nó thật sự mang ra công sức mật mã mà người khác không thể sao chép: biến các đường ray tuân thủ đa chuỗi thành một tấm lưới an toàn liền mạch, phủ kín khắp nơi.

Nhiều người nhìn @NewtonProtocol và thấy quen mắt, tưởng nó lại là một trong đống dự án “dán ghép” ZK, MPC hoặc mã hóa đồng cấu ngoài thị trường. Nhưng nếu bạn lật kỹ whitepaper của nó, bạn sẽ thấy nó có rất nhiều điểm nổi bật độc nhất.

Nhãn đầu tiên tên là Newton Rego. Các dự án khác làm chiến lược kiểm soát rủi ro thì chỉ có thể dùng bộ quy tắc sẵn có để thực hiện các phép phán đoán điều kiện đơn giản. Nhưng $NEWT đã “chế” trực tiếp bộ biên dịch Rego chuẩn cho doanh nghiệp, nhét vào trong đó một gói mở rộng mật mã riêng.

Điều này khiến cho người phụ trách tuân thủ khi viết cùng một câu lệnh khai báo (declarative) không chỉ có thể làm sàng lọc bằng danh sách đen truyền thống, mà còn có thể gọi trực tiếp các giao diện lớp dưới để khôi phục chữ ký nhận dạng liên chuỗi (cross-chain) của secp256k1 và Ed25519. Cú pháp liên kết nguyên tử việc phán định multi-sig ngoài chuỗi với “gốc tin cậy” nguyên bản liên chuỗi là duy nhất trong Web3.

Nhãn thứ hai là “Newton privacy envelope” của #newt . Đa số dự án trên thị trường chơi quyền riêng tư thì về cơ bản chỉ là trò “bộ mã hóa rồi gửi đi” kiểu giao chìa khóa trao tay; còn NPE là một cấu trúc mật mã có độ tổ hợp cao. Nó vừa sử dụng mã hóa ngưỡng (threshold encryption), vừa bắt buộc người dùng + DApp phải ủy quyền bằng chữ ký kép. Phần “hardcore” nhất là ở lớp wire format, nó khóa chặt bản mã vào đúng bộ máy khách (client) theo chính sách cụ thể và mục đích giao dịch đơn lẻ. Bất kỳ hacker hay nút độc hại nào cũng tuyệt đối không thể sao chép lại hoặc chuyển dụng dữ liệu quyền riêng tư này trong bối cảnh khác. Từ gốc rễ, nó cắt đứt các cuộc tấn công man-in-the-middle.

Thứ khiến người ta nổi da gà và gần như không thể bị dự án khác “copy” lại chính là cơ chế thách thức phạt (ZK slashing) của nó. Các dự án khác làm ZK thì thường phải viết mạch tùy biến cho từng nghiệp vụ tuân thủ cụ thể một cách thủ công, vừa đau khổ mà lại không dùng chung được. Nhưng Newton lại tận dụng ngôn ngữ Rego với các hàm thuần (pure function) và tính chất toán học tuyệt đối xác định: thay vì làm mạch riêng, nó nhét thẳng toàn bộ trình thông dịch ngôn ngữ Rego vào trong SP1 hoặc Risc0 của máy ảo ZK!

Kết quả là bất kỳ nhân sự kiểm soát rủi ro nào chỉ cần viết một dòng mã, phía dưới sẽ tự động có thuộc tính có thể chứng minh bằng ZK. Khi bên thách thức bên ngoài phát hiện nút gian lận, có thể trực tiếp dùng bằng chứng ZK “chung” này để lật ngược ngay các nút gian lận trên EigenLayer, kích hoạt tức thì việc phạt tịch thu tài sản trên chuỗi; thậm chí để phối hợp với hệ thống điện toán đó, chỉ cần nút đặt cược (staking) một lần trên mainnet Ethereum, là có thể dùng cây Merkle của BLS để đồng bộ an toàn trọng số điện toán tới tất cả các L2 phổ biến.

Gần đây tôi cắt một bộ script tần suất cao, bị lỗi và số chip 2000U trên @grvt_io cũng thử bắt cơ hội arbitrage. Đơn thì vào khá nhiều, nhưng đến lúc đối soát tôi trực tiếp ngớ người: vài lệnh đáng lẽ phải “ăn thịt” thì giá khớp thực tế lại lệch thẳng vài điểm cơ bản so với giá công bằng trên sàn. Phiên giao dịch thực lần này khiến tôi hoàn toàn tỉnh ra: bên dự án quảng bá sổ lệnh quyền riêng tư phi tập trung (off-chain) có thể ngăn kẹp, nhưng trong tình huống biến động cực đoan, chúng tôi thực ra đang trả “phí thuế ẩn” cho kiểu quyền riêng tư không nhìn thấy được đó.

#grvt là một trong những điểm bán hàng cốt lõi có việc đưa vào sổ lệnh quyền riêng tư mã hoá được dẫn dắt bởi công nghệ zero-knowledge. Cốt lõi của nó là trộn và mã hoá toàn bộ lệnh treo, giá đặt và độ sâu của người dùng trên toàn mạng ở ngoài chuỗi; nhờ đó, các robot kẹp “ba bên” và đội lượng hoá săn mồi trên mainnet căn bản không lấy được dữ liệu từ mempool. Điều này có nghĩa là gì? Khi bạn đặt lệnh trong hệ thống đó, về lý thuyết bạn có mức độ chống bị săn bắt (anti-hunting) rất cao.

Nhưng tạt một gáo nước lạnh: trong tình huống thị trường cực đoan, hệ thống này lại tạo ra một nhược điểm cứng khác—đó là trượt giá dạng “hộp mù” do tính minh bạch thanh khoản kém. Vì toàn bộ độ sâu sổ lệnh đối với thị trường là một “lỗ đen” hoàn toàn kín, người giao dịch bình thường và nhà tạo lập thanh khoản bên thứ ba không thể quan sát theo thời gian thực độ dày lệnh thực ở các mức giá khác nhau như trên sàn truyền thống.

Tối qua khi thị trường hoảng loạn giẫm đạp, độ sâu thực trong mạng lưới mã hoá ngoài chuỗi đã bị phân tầng nghiêm trọng. Nhưng phía front-end vẫn hiển thị bình thường do dữ liệu bị cách ly. Lệnh mua của tôi lao thẳng vào vùng chân không thiếu độ sâu công khai, khiến lệnh đáng lẽ phải chốt lời lại bị ăn vào “khoảng chênh giá ẩn”. Cái bị động của “không nhìn thấy sổ lệnh” trong những thị trường mà từng giây đều giành giật nhau là cực kỳ chí mạng.

Nhưng nói theo hướng ngược lại: vừa phàn nàn về màn sương trượt giá đó xong, thì cũng không thể không thừa nhận rằng cơ chế thanh lý tự động chống làm ác trên chuỗi của nó tuy nhiên lại “giẫm” rất chắc lên đường ranh giới tiền.

Điểm khiến người ta khó chịu nhất ở nền tảng truyền thống là rút cáp và kích nổ có chủ đích theo kiểu nhắm trúng điểm. Việc thanh lý cắt margin của chúng hoàn toàn được chạy bằng mã “hộp đen” trong máy chủ trung tâm. Nhưng #grvt lại chốt chặt đường ranh giới thanh lý cốt lõi và việc xác thực trạng thái tài khoản trong các hợp đồng thông minh trên chuỗi. Có cần phải tự động giảm vị thế cưỡng bức hay không là do mã hợp đồng thông minh công khai chạy ra—phía nền tảng cũng không thể can thiệp để thay đổi đường thanh lý của bạn.

Tóm lại, #grvt dù hi sinh độ minh bạch của sổ lệnh, nhưng cũng giúp cho nhà đầu tư lẻ bẻ gãy “viên đạn độc” nhất—giết chết việc ông trùm (nhà tạo lập) làm ác.

Dạo gần đây tôi phát hiện @NewtonProtocol đã tốn khá nhiều dung lượng để nói về Attestation, Verification và Replay. Ban đầu tôi thật sự không hiểu lắm, vì theo nhận thức của mình, chỉ cần kết quả cuối cùng đúng thì dường như chuyện “trong quá trình đó được làm như thế nào” không quan trọng. Người thực thi là ai, trong quá trình thực thi đã xảy ra những gì—những thứ đó giống như chi tiết triển khai hơn là điều mà giao thức thực sự quan tâm.

Cho đến khi sau này tôi sắp lại toàn bộ luồng thực thi từ đầu: từ Transaction Intent đi vào Gateway, đến Policy Evaluation, rồi Operator thực hiện, sau đó mới đến phần Attestation. Lúc đó tôi mới nhận ra nghi vấn của mình nằm ở đâu.

$NEWT có vẻ như thứ mà nó thực sự quan tâm không phải là việc kết quả có đúng hay không, mà là vì sao kết quả đó đáng tin. Transaction Intent không phải cứ đi vào hệ thống là lập tức được thực thi; nó trước tiên phải trải qua Policy Evaluation. Operator hoàn thành xong nhiệm vụ cũng không đồng nghĩa ngay lập tức trở thành kết quả cuối cùng; phía sau còn cần Attestation, và nếu cần thì thậm chí có thể Replay.

Cứ nhìn tiếp, tôi càng thấy rằng: rốt cuộc chúng đều đang trả lời câu hỏi—việc thực thi này có được tiến hành đúng theo các quy tắc mà cả mạng cùng công nhận hay không?

Đến đây tôi mới nhận ra #Newt ghi lại không phải là kết quả của một lần thực thi, mà là cả quá trình của một lần thực thi. Sau đó tôi lại cẩn thận ngẫm nghĩ, và chợt nghĩ đến một câu hỏi mà trước đây mình chưa từng nghiêm túc cân nhắc.

Vì sao nhiều hệ thống lại tập trung vào kết quả chứng minh, còn Newton thì lại tốn nhiều công sức để chứng minh quá trình?

Tôi càng lúc càng cảm thấy rằng đằng sau hai kiểu thiết kế này thực ra là hai cách đặt niềm tin hoàn toàn khác nhau: nếu chỉ chứng minh kết quả, thì cuối cùng bạn vẫn phải tin người đã nói với bạn rằng kết quả đúng. Nhưng nếu toàn bộ quá trình thực thi có thể được kiểm chứng, thì thứ thực sự cần tin không còn là một Operator nào đó, mà là “đường đi” của quá trình thực thi—mà bất kỳ ai cũng có thể lặp lại và tự kiểm chứng.

Vì vậy tôi nghĩ Newton thực sự không phải muốn tái cấu trúc luồng thực thi; nó đang thách thức một giả định mặc định đã tồn tại nhiều năm: rằng kết quả đúng là đủ rồi.

Ít nhất theo Newton có vẻ là chưa đủ.

Có lẽ đây mới là ý nghĩa thật sự của Attestation, Verification và Replay. Chúng không bảo vệ chỉ riêng kết quả, mà bảo vệ toàn bộ quá trình khiến kết quả đó trở nên đúng đắn.

Trong mấy ngày nay tôi cứ lục đọc blog của @grvt_io , và có một từ xuất hiện đặc biệt thường xuyên: Capital Productivity. Ban đầu tôi thật ra cũng không để ý nhiều, chỉ nghĩ đây là một khái niệm marketing. Cuối cùng thì sàn giao dịch còn không phải vẫn dựa vào thanh khoản, phí giao dịch và tốc độ giao dịch sao? Một nền tảng giao dịch mà cứ nói về năng suất vốn thì nghe cũng hơi không giống điều mà sàn giao dịch nên nói.

Vì vậy khi lần đầu thấy One Balance, Unified Margin, tôi vẫn cứ lý giải theo hướng tối ưu trải nghiệm. Sau đó tôi lại gom vài bài blog lại và đọc lại một lượt, ban đầu chỉ muốn hiểu Unified Margin rốt cuộc giải quyết vấn đề gì, nhưng càng xem càng thấy kỳ lạ.

Phía chính thức gần như không bàn nhiều về tốc độ giao dịch, cũng không cứ nhấn mạnh Hybrid Exchange, mà ngược lại liên tục nhắc đến Capital Productivity, Capital Drag, thậm chí cả Yield Layer phía sau—câu chuyện thảo luận dường như luôn xoay quanh đúng một điều.

Lúc này tôi mới nhận ra có lẽ mình đã hiểu sai từ đầu: GRVT dường như vẫn đang đặt một câu hỏi khác—tại sao một đơn vị vốn lại chỉ có thể đảm nhận một mục đích? Chính ở đây, tôi mới hiểu vì sao phía chính thức cứ nhấn mạnh Capital Drag. Thứ có thể bị lãng phí thật sự không phải là tốc độ giao dịch, mà là quá trình vốn liên tục phải chờ đợi, di chuyển và cấu hình lại.

Sau đó tôi quay lại xem One Balance, Unified Margin, Yield Layer, và bất chợt phát hiện chúng trông như ba tính năng khác nhau, nhưng thực ra đều đang trả lời câu hỏi: có thể để cho cùng một đơn vị vốn—không vì đổi mục đích mà phải dừng lại—được hay không.

Vì vậy, bây giờ nhìn lại, tôi càng cảm thấy GRVT muốn tái cấu trúc thực sự có lẽ không phải là sàn giao dịch. Thứ nó vẫn đang thách thức là một thói quen mặc định của hệ thống tài chính mà gần như chẳng ai nghi ngờ: vì sao vốn, khi đã hoàn thành một nhiệm vụ, thì phải kết thúc đoạn đó rồi mới bắt đầu đoạn tiếp theo?

Ít nhất bây giờ tôi càng nghiêng về một cách hiểu: thứ GRVT thực sự muốn giữ lại không phải là một tài khoản nào đó, cũng không phải là một loại sản phẩm nào đó, mà là tính liên tục của cùng một đơn vị vốn.
Giao dịch, lợi nhuận, đầu tư, thanh toán—rõ ràng không phải là bốn phần vốn tách biệt nhau, mà nên là cùng một đơn vị vốn, đảm nhận những vai trò khác nhau ở các giai đoạn khác nhau.

Thế nên bây giờ khi nhìn Capital Productivity, tôi lại cảm thấy nó thật sự muốn tối ưu không phải là hiệu suất giao dịch, mà là cách vốn vận hành trong toàn bộ hệ thống tài chính.
#grvt

Lâu lắm rồi mình mới đến TGE mới. Mấy hôm nay dự án @grvt_io vừa ra mắt lại là một “cú to” nữa.

@grvt_io còn tung ra sự kiện Booster cực kỳ giá trị: chỉ cần 2 điểm là có thể đổi lấy token trị giá 8u, mọi người đừng bỏ lỡ.

Khi mới xem HEX Architecture của @grvt_io , mình cứ thắc mắc một điều: nếu việc khớp lệnh xảy ra ngoài chuỗi thì rốt cuộc trên chuỗi làm sao để tin tưởng?

Theo cách mình hiểu, giá trị lớn nhất của blockchain chính là tính xác định. Nếu bước khớp lệnh cốt lõi rời khỏi chuỗi thì khác gì so với các sàn giao dịch truyền thống? Ban đầu mình nghĩ GRVT chỉ là một thỏa hiệp giữa hiệu năng và phi tập trung. Nhưng khi xem lại toàn bộ luồng thực thi của nó, mình mới phát hiện ra mình đã hiểu sai từ đầu.

#grvt không thực sự giải quyết vấn đề “đặt giao dịch ở đâu”, mà là làm thế nào để trạng thái giao dịch sinh ra ngoài chuỗi cuối cùng được chuỗi chấp nhận. Trong thiết kế của nó, lệnh đầu tiên được đưa vào Off-chain Matching Engine để thực hiện khớp lệnh. Nhờ vậy, giao dịch tần suất cao không cần chờ xác nhận trên chuỗi, từ đó đạt hiệu suất thực thi gần như sàn truyền thống.

Điểm thú vị là: việc khớp lệnh không đồng nghĩa với trạng thái sẽ được xác lập vĩnh viễn. Kết quả giao dịch cần thông qua On-chain Settlement, tức là chuỗi thực hiện xác nhận cuối cùng bằng các quy tắc trên chuỗi và hợp đồng thông minh. Nói cách khác, off-chain chịu trách nhiệm tính toán tần suất cao, còn on-chain chịu trách nhiệm về trạng thái cuối cùng.

Đến đây mình mới nhận ra #grvt đang cố gắng tách ranh giới giữa việc tạo ra trạng thái và việc định nghĩa/ xác nhận trạng thái. Matching Engine chịu trách nhiệm tạo ra kết quả giao dịch, Settlement Layer chịu trách nhiệm xác nhận trạng thái tài sản, còn Smart Contract Vault chịu trách nhiệm đảm bảo tài sản của người dùng không hoàn toàn phụ thuộc vào sổ cái tập trung.

Vì vậy mình cảm thấy Hybrid Exchange không chỉ đơn giản là ghép CEX và DEX lại với nhau. Thứ nó thay đổi thực sự là ranh giới niềm tin trong hệ thống giao dịch. Các bước của giao dịch không nhất thiết phải diễn ra toàn bộ trên chuỗi, nhưng tác động cuối cùng đến trạng thái tài sản của người dùng nhất định phải được quy tắc trên chuỗi xác nhận.

Sau đó xem Unified Balance, mình nhận ra logic này không chỉ tồn tại trong quyết toán giao dịch, mà xuyên suốt toàn bộ việc quản lý trạng thái tài sản. Giao dịch, ký quỹ và lợi nhuận không còn là các trạng thái tài khoản rời rạc nữa, mà luân chuyển trong cùng một hệ thống thống nhất. Nhờ đó, tài sản không bị “đóng khung” trong một ngữ cảnh cụ thể, mà có thể liên tục thay đổi.

Giờ mình để xem GRVT giống như đang giải quyết một cơ chế: làm thế nào để trạng thái sinh ra ngoài chuỗi bước vào hiện thực của thế giới trên chuỗi, và trở thành hiện thực được thế giới trên chuỗi công nhận.

Tôi luôn cảm thấy rằng điều quan trọng nhất của một hệ thống ủy quyền (authorization) là các quy tắc.

Chỉ cần Policy được viết đủ chặt chẽ, hệ thống có thể xác định giao dịch nào nên được thực hiện và giao dịch nào phải bị từ chối. Vì vậy, ngay từ đầu khi đọc Whitepaper số @NewtonProtocol , tôi đã tập trung vào Rego Policy và Authorization Flow.

Mãi đến sau này khi lật lại phần Data Provider, tôi mới nhận ra mình đã bỏ qua một vấn đề tầng thấp hơn: nếu các quy tắc có chính xác đến đâu, mà dữ liệu đầu vào không đáng tin cậy thì phán quyết cuối cùng vẫn sẽ không có ý nghĩa.

Policy Evaluation của $NEWT không phải là trực tiếp chạy các quy tắc. Operator cần gọi các dữ liệu bên ngoài như Oracle Price, Sanctions Feed, Risk Score…, sau đó đưa các đầu vào này vào Rego Policy để đánh giá. Nhưng bản thân những dữ liệu đó lại không tồn tại nguyên sinh trên chuỗi. Và ngay lúc đó tôi nhận ra dường như đây là vấn đề mà tất cả các hệ thống tự động hóa trên chuỗi đều gặp phải. Mọi người vẫn hay thảo luận liệu smart contract có đáng tin hay không, nhưng rất ít khi hỏi rằng dữ liệu mà hệ thống dùng để đưa ra quyết định—nó có thực sự đáng tin không?

Nếu việc đánh giá trạng thái địa chỉ bị sai, hoặc điểm rủi ro bị lệch, hay dữ liệu thu được ở các nút khác nhau không nhất quán, thì dù phần Policy, Attestation và Consensus phía sau có tính đúng đi chăng nữa, kết quả cũng có thể chỉ là “đúng” dựa trên các dữ liệu đầu vào sai.

Thiết kế của #newt cho vấn đề này rất thú vị: nó không chọn trở thành nhà cung cấp dữ liệu duy nhất, mà biến Data Provider thành một mô-đun có thể cắm thêm (plug-in). Operator có thể độc lập thực thi WASM Data Provider, lấy dữ liệu từ môi trường bên ngoài trong vùng cách ly, và tạo ECDSA Attestation dựa trên dữ liệu mình quan sát được để đưa chính bản thân dữ liệu đầu vào đó vào phạm vi được kiểm chứng.

Đến đây tôi mới nhận ra trước đó mình đã hiểu sai: tôi cứ tưởng cốt lõi của Newton là làm cho các quy tắc có thể được xác thực (verifiable). Nhưng thực ra, điều nó cần giải quyết trước tiên là đảm bảo rằng khi các quy tắc được chạy, chúng phải đối mặt với cùng một thực tại đáng tin cậy. Policy quyết định hệ thống sẽ đánh giá như thế nào, còn Data Provider quyết định hệ thống nhìn thấy gì.

Phần thực sự khó khăn chưa bao giờ là làm sao để máy móc chạy theo đúng quy tắc; mà là trước khi máy đưa ra quyết định, phải đảm bảo thế giới mà máy nhìn thấy không bị thay đổi bởi các dữ liệu đầu vào sai. Có lẽ đó mới chính là ý nghĩa của việc $NEWT thiết kế Data Provider Ecosystem.

Trong tương lai, cạnh tranh của các hệ thống trên chuỗi không chỉ nằm ở quy tắc và cơ chế thực thi, mà còn ở việc ai có thể làm cho toàn mạng trước khi đưa ra quyết định, đều dựa trên cùng một thực tại.