W Shakespeare

Một chi tiết trong API của GRVT đã thu hút sự chú ý của tôi. Bên cạnh API gốc, GRVT cũng hỗ trợ tích hợp thông qua CCXT, cho phép các nhà phát triển kết nối bằng cùng một giao diện mà họ đã dùng trên nhiều sàn giao dịch khác. Ban đầu, điều đó trông như một tính năng tương thích đơn giản. Rồi tôi nhận ra GRVT đang giảm một khoản chi phí xuất hiện ngay cả trước khi quá trình phát triển sản phẩm bắt đầu. Khoản chi phí đó nằm trong lớp tích hợp, từ rất sớm—khi các nhà phát triển thậm chí chưa có cơ hội cải thiện chính hệ thống giao dịch. Nhiều nhà phát triển đã xây dựng bot giao dịch, các hệ thống giao dịch thuật toán dựa trên CCXT. Mã tích hợp của họ, các lớp trừu tượng và quy trình triển khai đã sẵn có. Việc thêm GRVT không yêu cầu phải thiết kế lại lớp tích hợp đó chỉ vì đã có thêm một sàn giao dịch khác. Điều này thay đổi nơi mà nỗ lực kỹ thuật bắt đầu. Thay vì phải xem xét lại khả năng kết nối, các nhà phát triển có thể tiếp tục xây dựng trên một lớp tích hợp mà họ đã tin tưởng. Thời gian được dành để tinh chỉnh logic thực thi, cải thiện mô hình giao dịch và thử nghiệm các ý tưởng mới—thay vì thay thế một hạ tầng đang hoạt động. Chi phí thực sự không phải là việc học thêm một API nữa. Đó là việc viết lại những hệ thống đã hoạt động trước khi quá trình phát triển có ý nghĩa kịp bắt đầu. Đó chính là nơi “Innovation Tax” (thuế đổi mới) âm thầm xuất hiện. Bằng cách hỗ trợ CCXT, GRVT tránh đưa ra khoản thuế đó. Mã tích hợp và các lớp trừu tượng hiện có vẫn có thể tái sử dụng, giúp nỗ lực kỹ thuật chuyển hướng thẳng tới những phần của hệ thống giao dịch thực sự tạo ra khác biệt. Lớp tích hợp không còn là nơi các nhà phát triển dành phần lớn thời gian để điều chỉnh phần mềm, mà trở thành một nền tảng ổn định để xây dựng dựa trên. Mức đánh đổi cũng rõ ràng. Bằng cách giảm Innovation Tax, GRVT cũng từ bỏ cơ hội cạnh tranh thông qua “ma sát” tích hợp hoặc trải nghiệm phát triển độc quyền. Khi khả năng kết nối trở nên quen thuộc, các nhà phát triển sẽ đánh giá GRVT trực tiếp hơn nhiều dựa trên chất lượng thực thi, năng lực sản phẩm và giá trị mà nền tảng tạo ra ngoài API của nó. Càng dễ kết nối, sản phẩm bản thân càng khó có đất để “tranh”—phải tự cạnh tranh bằng chính mình. @grvt_io #grvt

Đúng một phần

Một chi tiết trong API của GRVT đã thu hút sự chú ý của tôi.
Bên cạnh API gốc, GRVT cũng hỗ trợ tích hợp thông qua CCXT, cho phép các nhà phát triển kết nối bằng cùng một giao diện mà họ đã dùng trên nhiều sàn giao dịch khác.
Ban đầu, điều đó trông như một tính năng tương thích đơn giản.
Rồi tôi nhận ra GRVT đang giảm một khoản chi phí xuất hiện ngay cả trước khi quá trình phát triển sản phẩm bắt đầu. Khoản chi phí đó nằm trong lớp tích hợp, từ rất sớm—khi các nhà phát triển thậm chí chưa có cơ hội cải thiện chính hệ thống giao dịch.
Nhiều nhà phát triển đã xây dựng bot giao dịch, các hệ thống giao dịch thuật toán dựa trên CCXT. Mã tích hợp của họ, các lớp trừu tượng và quy trình triển khai đã sẵn có. Việc thêm GRVT không yêu cầu phải thiết kế lại lớp tích hợp đó chỉ vì đã có thêm một sàn giao dịch khác.
Điều này thay đổi nơi mà nỗ lực kỹ thuật bắt đầu.
Thay vì phải xem xét lại khả năng kết nối, các nhà phát triển có thể tiếp tục xây dựng trên một lớp tích hợp mà họ đã tin tưởng. Thời gian được dành để tinh chỉnh logic thực thi, cải thiện mô hình giao dịch và thử nghiệm các ý tưởng mới—thay vì thay thế một hạ tầng đang hoạt động.
Chi phí thực sự không phải là việc học thêm một API nữa. Đó là việc viết lại những hệ thống đã hoạt động trước khi quá trình phát triển có ý nghĩa kịp bắt đầu. Đó chính là nơi “Innovation Tax” (thuế đổi mới) âm thầm xuất hiện.
Bằng cách hỗ trợ CCXT, GRVT tránh đưa ra khoản thuế đó. Mã tích hợp và các lớp trừu tượng hiện có vẫn có thể tái sử dụng, giúp nỗ lực kỹ thuật chuyển hướng thẳng tới những phần của hệ thống giao dịch thực sự tạo ra khác biệt. Lớp tích hợp không còn là nơi các nhà phát triển dành phần lớn thời gian để điều chỉnh phần mềm, mà trở thành một nền tảng ổn định để xây dựng dựa trên.
Mức đánh đổi cũng rõ ràng. Bằng cách giảm Innovation Tax, GRVT cũng từ bỏ cơ hội cạnh tranh thông qua “ma sát” tích hợp hoặc trải nghiệm phát triển độc quyền. Khi khả năng kết nối trở nên quen thuộc, các nhà phát triển sẽ đánh giá GRVT trực tiếp hơn nhiều dựa trên chất lượng thực thi, năng lực sản phẩm và giá trị mà nền tảng tạo ra ngoài API của nó. Càng dễ kết nối, sản phẩm bản thân càng khó có đất để “tranh”—phải tự cạnh tranh bằng chính mình.
@grvt_io #grvt

Nhìn lại cuộc thi giao dịch theo khối lượng GRVT tại KR / JP / CN, tôi không nghĩ đó chỉ là một chiến dịch giao dịch thông thường. Sự kiện diễn ra từ ngày 2 tháng 2 đến ngày 22 tháng 2, và người tham gia chọn một trong ba vị trí theo quốc gia. Sau khi xem lại các quy tắc, tôi cho rằng chiến dịch này vừa giải quyết hai vấn đề khác nhau cùng lúc. Vấn đề thứ nhất là xây dựng thanh khoản ở đâu. Việc chọn Hàn Quốc, Nhật Bản và Trung Quốc không phải ngẫu nhiên. Đây là ba trong số những khu vực giao dịch crypto hoạt động nhất thế giới, có thanh khoản sâu và cộng đồng giao dịch rất sôi động. Nếu GRVT muốn tăng cường thanh khoản trước TGE token $GRVT sắp tới, thì việc tập trung chiến dịch vào các thị trường này sẽ mang lại cơ hội tốt nhất để thu hút hoạt động giao dịch có ý nghĩa. Vấn đề thứ hai là ai sẽ tạo ra thanh khoản đó. GRVT đã loại trừ rõ ràng các tài khoản thuộc tổ chức, gắn với công ty và theo chiến lược. Nếu mục tiêu đơn thuần là tối đa hóa khối lượng giao dịch, thì quyết định này sẽ chẳng có ý nghĩa gì. Các bên tham gia theo mô hình tổ chức có thể tạo ra những con số lớn hơn nhiều với chỉ cần ít tài khoản hơn. Thay vào đó, GRVT tăng khả năng hoạt động tạo ra khối lượng của họ đến từ người dùng lẻ. Điều đó giúp sàn giao dịch có cơ hội tốt hơn để thu hút nhiều tài khoản có vốn hơn, nhiều nhà giao dịch hoạt động hơn, nhiều giao dịch hơn, và hoạt động giao dịch được lan tỏa trên một nền tảng người dùng rộng hơn nhiều, thay vì bị dồn vào một vài tài khoản lớn. Sự khác biệt không chỉ nằm ở góc độ thống kê. Những chỉ số đó tạo nên một bức tranh hoàn toàn khác về sàn giao dịch GRVT. Thay vì trông giống một sàn có hoạt động phụ thuộc vào một vài người chơi lớn, @grvt_io có cơ hội cao hơn để trông giống một nền tảng nơi sự tham gia diễn ra rộng khắp, mang tính tự nhiên và được dẫn dắt bởi cộng đồng. Cuộc thi kết thúc vào tháng Hai. Kết quả của nó có thể sẽ không hiển thị đầy đủ cho đến khi $GRVT đạt đến thị trường. Nếu chiến lược này hiệu quả, cuộc thi sẽ không chỉ được nhớ đến vì thanh khoản mà nó giúp xây dựng, mà còn vì câu chuyện mà GRVT có thể kể về sàn giao dịch khi token cuối cùng được ra mắt. $LAB #grvt

Đúng một phần

Nhìn lại cuộc thi giao dịch theo khối lượng GRVT tại KR / JP / CN, tôi không nghĩ đó chỉ là một chiến dịch giao dịch thông thường.
Sự kiện diễn ra từ ngày 2 tháng 2 đến ngày 22 tháng 2, và người tham gia chọn một trong ba vị trí theo quốc gia.
Sau khi xem lại các quy tắc, tôi cho rằng chiến dịch này vừa giải quyết hai vấn đề khác nhau cùng lúc.
Vấn đề thứ nhất là xây dựng thanh khoản ở đâu.
Việc chọn Hàn Quốc, Nhật Bản và Trung Quốc không phải ngẫu nhiên. Đây là ba trong số những khu vực giao dịch crypto hoạt động nhất thế giới, có thanh khoản sâu và cộng đồng giao dịch rất sôi động. Nếu GRVT muốn tăng cường thanh khoản trước TGE token $GRVT sắp tới, thì việc tập trung chiến dịch vào các thị trường này sẽ mang lại cơ hội tốt nhất để thu hút hoạt động giao dịch có ý nghĩa.
Vấn đề thứ hai là ai sẽ tạo ra thanh khoản đó.
GRVT đã loại trừ rõ ràng các tài khoản thuộc tổ chức, gắn với công ty và theo chiến lược.
Nếu mục tiêu đơn thuần là tối đa hóa khối lượng giao dịch, thì quyết định này sẽ chẳng có ý nghĩa gì. Các bên tham gia theo mô hình tổ chức có thể tạo ra những con số lớn hơn nhiều với chỉ cần ít tài khoản hơn.
Thay vào đó, GRVT tăng khả năng hoạt động tạo ra khối lượng của họ đến từ người dùng lẻ.
Điều đó giúp sàn giao dịch có cơ hội tốt hơn để thu hút nhiều tài khoản có vốn hơn, nhiều nhà giao dịch hoạt động hơn, nhiều giao dịch hơn, và hoạt động giao dịch được lan tỏa trên một nền tảng người dùng rộng hơn nhiều, thay vì bị dồn vào một vài tài khoản lớn.
Sự khác biệt không chỉ nằm ở góc độ thống kê.
Những chỉ số đó tạo nên một bức tranh hoàn toàn khác về sàn giao dịch GRVT. Thay vì trông giống một sàn có hoạt động phụ thuộc vào một vài người chơi lớn, @grvt_io có cơ hội cao hơn để trông giống một nền tảng nơi sự tham gia diễn ra rộng khắp, mang tính tự nhiên và được dẫn dắt bởi cộng đồng.
Cuộc thi kết thúc vào tháng Hai.
Kết quả của nó có thể sẽ không hiển thị đầy đủ cho đến khi $GRVT đạt đến thị trường.
Nếu chiến lược này hiệu quả, cuộc thi sẽ không chỉ được nhớ đến vì thanh khoản mà nó giúp xây dựng, mà còn vì câu chuyện mà GRVT có thể kể về sàn giao dịch khi token cuối cùng được ra mắt.
$LAB #grvt

LIỆU NEWTON MAINNET BETA CÓ PHẢI LÀ NỖ LỰC ĐƯA MỘT THESIS TRỞ LẠI TRUNG TÂM THỊ TRƯỜNG?Có một suy nghĩ xuất hiện trong đầu tôi khi Newton Protocol công bố Mainnet Beta. Liệu đây chỉ đơn thuần là một cột mốc kỹ thuật, hay còn là thời điểm Newton cố gắng đưa chính thesis của mình trở lại trung tâm của thị trường? Tôi nghĩ đây là một giả thuyết đáng để suy ngẫm. Nếu quay lại vài năm trước, khi Newton bắt đầu xây dựng protocol, thị trường crypto vẫn chủ yếu xoay quanh Layer 1, Restaking, Modular hay các narrative về hiệu suất. AI Agent gần như chưa tồn tại ở quy mô đủ lớn. Regulation vẫn còn là câu chuyện "crypto có được chấp nhận hay không". Còn programmable authorization hay policy engine là những khái niệm khá xa lạ với phần lớn thị trường. Nếu Newton nói về những thứ đó vào thời điểm ấy, rất có thể vấn đề không nằm ở công nghệ. Mà nằm ở việc thị trường chưa thực sự cảm nhận được nhu cầu. Nhưng bối cảnh hiện tại đã khác. AI đang dần chuyển từ việc tạo nội dung sang thực hiện hành động. Ngày càng có nhiều cuộc thảo luận về Agent Wallet, AI Commerce hay việc AI trực tiếp tương tác với blockchain. Crypto cũng không còn chỉ chạy theo narrative. Sau nhiều chu kỳ, thị trường bắt đầu đòi hỏi những hạ tầng có thể tham gia vào dòng tiền thực thay vì chỉ hứa hẹn về một tương lai xa. Trong khi đó, regulation cũng dịch chuyển từ câu hỏi "có nên quản lý crypto hay không" sang "quản lý bằng cách nào". Khi blockchain tiến gần hơn đến môi trường có tổ chức và có yêu cầu tuân thủ, policy và authorization bắt đầu trở thành những khái niệm dễ được chấp nhận hơn trước. Chính vì vậy, tôi bắt đầu tự hỏi liệu Mainnet Beta lần này có đang mang một ý nghĩa khác. Có thể Newton không thay đổi thesis. Thứ thay đổi là thị trường. Những gì từng bị xem là một bài toán quá sớm lại bắt đầu trở thành một nhu cầu có thật. Và Mainnet Beta là thời điểm Newton đưa thesis đó ra môi trường production đúng lúc thị trường đã có nhiều lý do hơn để quan tâm đến nó. Nếu nhìn theo hướng này, Mainnet Beta không chỉ là một lần triển khai hạ tầng. Nó cũng có thể là một phép thử. Không phải phép thử dành cho công nghệ, vì phần lớn nền tảng của Newton đã được xây dựng từ trước. Mà là phép thử dành cho chính thị trường. Sau nhiều năm, liệu thị trường đã sẵn sàng cho thesis mà Newton theo đuổi hay vẫn còn quá sớm? Nhưng cũng chính ở đây xuất hiện một rủi ro rất lớn. Nếu giả thuyết trên đúng, Mainnet Beta sẽ không tự động đưa Newton trở lại trung tâm của thị trường. Bởi một thesis đúng không đồng nghĩa với việc thị trường sẽ chấp nhận nó ngay lập tức. AI Agent vẫn đang ở giai đoạn đầu. Phần lớn ứng dụng onchain vẫn chưa cần một authorization layer đủ phức tạp. Regulation tuy rõ ràng hơn, nhưng tốc độ triển khai trong thực tế vẫn chậm hơn rất nhiều so với tốc độ phát triển của công nghệ. Điều đó có nghĩa Newton có thể đang bước vào một giai đoạn rất khó. Thị trường đã bắt đầu nhìn thấy vấn đề, nhưng chưa chắc đã đủ trưởng thành để tạo ra adoption ở quy mô lớn. Nếu khoảng cách đó kéo dài, Mainnet Beta có thể giúp Newton lấy lại sự chú ý, nhưng chưa chắc giúp protocol đạt được tốc độ tăng trưởng tương xứng. Theo tôi, đây mới là điều đáng quan sát trong những tháng tới. Mainnet Beta không chỉ trả lời câu hỏi @NewtonProtocol đã sẵn sàng hay chưa. Nó còn trả lời một câu hỏi lớn hơn nhiều. Liệu Newton Protocol đang cố bắt kịp một thị trường đã thay đổi, hay họ đang kiểm chứng xem cuối cùng thị trường có bắt kịp thesis mà mình đã theo đuổi từ nhiều năm trước hay không? $LAB $NEWT #Newt

Đã xác minh

Bài viết

LIỆU NEWTON MAINNET BETA CÓ PHẢI LÀ NỖ LỰC ĐƯA MỘT THESIS TRỞ LẠI TRUNG TÂM THỊ TRƯỜNG?

Có một suy nghĩ xuất hiện trong đầu tôi khi Newton Protocol công bố Mainnet Beta.
Liệu đây chỉ đơn thuần là một cột mốc kỹ thuật, hay còn là thời điểm Newton cố gắng đưa chính thesis của mình trở lại trung tâm của thị trường?
Tôi nghĩ đây là một giả thuyết đáng để suy ngẫm.
Nếu quay lại vài năm trước, khi Newton bắt đầu xây dựng protocol, thị trường crypto vẫn chủ yếu xoay quanh Layer 1, Restaking, Modular hay các narrative về hiệu suất. AI Agent gần như chưa tồn tại ở quy mô đủ lớn. Regulation vẫn còn là câu chuyện "crypto có được chấp nhận hay không". Còn programmable authorization hay policy engine là những khái niệm khá xa lạ với phần lớn thị trường.
Nếu Newton nói về những thứ đó vào thời điểm ấy, rất có thể vấn đề không nằm ở công nghệ. Mà nằm ở việc thị trường chưa thực sự cảm nhận được nhu cầu.
Nhưng bối cảnh hiện tại đã khác.
AI đang dần chuyển từ việc tạo nội dung sang thực hiện hành động. Ngày càng có nhiều cuộc thảo luận về Agent Wallet, AI Commerce hay việc AI trực tiếp tương tác với blockchain.
Crypto cũng không còn chỉ chạy theo narrative. Sau nhiều chu kỳ, thị trường bắt đầu đòi hỏi những hạ tầng có thể tham gia vào dòng tiền thực thay vì chỉ hứa hẹn về một tương lai xa.
Trong khi đó, regulation cũng dịch chuyển từ câu hỏi "có nên quản lý crypto hay không" sang "quản lý bằng cách nào". Khi blockchain tiến gần hơn đến môi trường có tổ chức và có yêu cầu tuân thủ, policy và authorization bắt đầu trở thành những khái niệm dễ được chấp nhận hơn trước.
Chính vì vậy, tôi bắt đầu tự hỏi liệu Mainnet Beta lần này có đang mang một ý nghĩa khác.
Có thể Newton không thay đổi thesis.
Thứ thay đổi là thị trường.
Những gì từng bị xem là một bài toán quá sớm lại bắt đầu trở thành một nhu cầu có thật. Và Mainnet Beta là thời điểm Newton đưa thesis đó ra môi trường production đúng lúc thị trường đã có nhiều lý do hơn để quan tâm đến nó.
Nếu nhìn theo hướng này, Mainnet Beta không chỉ là một lần triển khai hạ tầng.
Nó cũng có thể là một phép thử.
Không phải phép thử dành cho công nghệ, vì phần lớn nền tảng của Newton đã được xây dựng từ trước.
Mà là phép thử dành cho chính thị trường.
Sau nhiều năm, liệu thị trường đã sẵn sàng cho thesis mà Newton theo đuổi hay vẫn còn quá sớm?
Nhưng cũng chính ở đây xuất hiện một rủi ro rất lớn.
Nếu giả thuyết trên đúng, Mainnet Beta sẽ không tự động đưa Newton trở lại trung tâm của thị trường. Bởi một thesis đúng không đồng nghĩa với việc thị trường sẽ chấp nhận nó ngay lập tức.
AI Agent vẫn đang ở giai đoạn đầu.
Phần lớn ứng dụng onchain vẫn chưa cần một authorization layer đủ phức tạp.
Regulation tuy rõ ràng hơn, nhưng tốc độ triển khai trong thực tế vẫn chậm hơn rất nhiều so với tốc độ phát triển của công nghệ.
Điều đó có nghĩa Newton có thể đang bước vào một giai đoạn rất khó. Thị trường đã bắt đầu nhìn thấy vấn đề, nhưng chưa chắc đã đủ trưởng thành để tạo ra adoption ở quy mô lớn. Nếu khoảng cách đó kéo dài, Mainnet Beta có thể giúp Newton lấy lại sự chú ý, nhưng chưa chắc giúp protocol đạt được tốc độ tăng trưởng tương xứng.
Theo tôi, đây mới là điều đáng quan sát trong những tháng tới.
Mainnet Beta không chỉ trả lời câu hỏi @NewtonProtocol đã sẵn sàng hay chưa.
Nó còn trả lời một câu hỏi lớn hơn nhiều.
Liệu Newton Protocol đang cố bắt kịp một thị trường đã thay đổi, hay họ đang kiểm chứng xem cuối cùng thị trường có bắt kịp thesis mà mình đã theo đuổi từ nhiều năm trước hay không?
$LAB $NEWT #Newt

Trước đây tôi cứ nghĩ Mainnet giống như màn khai bóng. Mạng bắt đầu hoạt động, các nhà xây dựng đến, và rồi mọi người dần dần tìm ra cách chơi. Tài liệu được cải thiện theo thời gian khi xuất hiện những câu hỏi mới. Nhịp điệu đó trở nên quá phổ biến trong crypto đến mức tôi hiếm khi tự hỏi về điều đó. Rồi tôi nhìn vào Newton Protocol. Trước Mainnet Beta, tài liệu dành cho nhà phát triển đã bao phủ rất nhiều thứ hơn chính bản thân giao thức. Có những hướng dẫn để kiểm thử chính sách, xâu chuỗi nhiều oracle dữ liệu, triển khai qua CLI hoặc Dashboard, mô phỏng chính sách end-to-end, quản lý bí mật, và sử dụng Policy Packs. Nó không chỉ mô tả các nhà phát triển có thể xây dựng gì, mà còn mô tả cách quy trình đó được kỳ vọng sẽ diễn ra. Điều đó khiến tôi nhìn về màn ra mắt theo một cách khác. Trong hầu hết các hệ sinh thái, tài liệu đi sau Mainnet. Các nhà phát triển cùng nhau khám phá các quy ước sau khi mạng đã hoạt động, và những quy ước đó dần dần trở thành các tiêu chuẩn không chính thức của cả hệ sinh thái. Newton dường như đảo ngược trình tự đó. Đến khi Mainnet Beta xuất hiện, phần lớn quy trình phát triển đã được ghi lại, được cấu trúc và được minh họa. Các nhà xây dựng không bắt đầu từ một trang trống mà bước vào một môi trường có sẵn quy trình kỹ thuật. Hệ quả còn lớn hơn mức nó trông thấy ban đầu. Khi mỗi đội tự khám phá quy trình của mình sau khi ra mắt, hệ sinh thái một cách tự nhiên sẽ tích lũy những thói quen kỹ thuật khác nhau. Theo thời gian, những thói quen đó trở thành sự phân mảnh. Khi quy trình đi trước, giao thức sẽ phân phối một tư duy kỹ thuật chung cùng với hạ tầng của nó. Các nhà phát triển vẫn được tự do xây dựng các ứng dụng khác nhau, nhưng họ bắt đầu với cùng những giả định về việc viết, kiểm thử, mô phỏng và triển khai chính sách. Đó là lý do vì sao thời điểm Newton Mainnet Beta lại gây chú ý với tôi. Có lẽ Mainnet chưa bao giờ được thiết kế như khoảnh khắc để nhà phát triển học các quy tắc. Newton Protocol dường như đảm bảo rằng “quyển sổ tay” đến trước, để khi lễ khai bóng cuối cùng diễn ra, hệ sinh thái có thể dành ít thời gian hơn cho việc tìm ra cách chơi và nhiều thời gian hơn cho việc quyết định nên xây dựng gì. @NewtonProtocol $LAB $NEWT #Newt

Đã xác minh

Trước đây tôi cứ nghĩ Mainnet giống như màn khai bóng.
Mạng bắt đầu hoạt động, các nhà xây dựng đến, và rồi mọi người dần dần tìm ra cách chơi. Tài liệu được cải thiện theo thời gian khi xuất hiện những câu hỏi mới. Nhịp điệu đó trở nên quá phổ biến trong crypto đến mức tôi hiếm khi tự hỏi về điều đó.
Rồi tôi nhìn vào Newton Protocol.
Trước Mainnet Beta, tài liệu dành cho nhà phát triển đã bao phủ rất nhiều thứ hơn chính bản thân giao thức. Có những hướng dẫn để kiểm thử chính sách, xâu chuỗi nhiều oracle dữ liệu, triển khai qua CLI hoặc Dashboard, mô phỏng chính sách end-to-end, quản lý bí mật, và sử dụng Policy Packs. Nó không chỉ mô tả các nhà phát triển có thể xây dựng gì, mà còn mô tả cách quy trình đó được kỳ vọng sẽ diễn ra.
Điều đó khiến tôi nhìn về màn ra mắt theo một cách khác.
Trong hầu hết các hệ sinh thái, tài liệu đi sau Mainnet. Các nhà phát triển cùng nhau khám phá các quy ước sau khi mạng đã hoạt động, và những quy ước đó dần dần trở thành các tiêu chuẩn không chính thức của cả hệ sinh thái.
Newton dường như đảo ngược trình tự đó.
Đến khi Mainnet Beta xuất hiện, phần lớn quy trình phát triển đã được ghi lại, được cấu trúc và được minh họa. Các nhà xây dựng không bắt đầu từ một trang trống mà bước vào một môi trường có sẵn quy trình kỹ thuật.
Hệ quả còn lớn hơn mức nó trông thấy ban đầu.
Khi mỗi đội tự khám phá quy trình của mình sau khi ra mắt, hệ sinh thái một cách tự nhiên sẽ tích lũy những thói quen kỹ thuật khác nhau. Theo thời gian, những thói quen đó trở thành sự phân mảnh.
Khi quy trình đi trước, giao thức sẽ phân phối một tư duy kỹ thuật chung cùng với hạ tầng của nó. Các nhà phát triển vẫn được tự do xây dựng các ứng dụng khác nhau, nhưng họ bắt đầu với cùng những giả định về việc viết, kiểm thử, mô phỏng và triển khai chính sách.
Đó là lý do vì sao thời điểm Newton Mainnet Beta lại gây chú ý với tôi.
Có lẽ Mainnet chưa bao giờ được thiết kế như khoảnh khắc để nhà phát triển học các quy tắc. Newton Protocol dường như đảm bảo rằng “quyển sổ tay” đến trước, để khi lễ khai bóng cuối cùng diễn ra, hệ sinh thái có thể dành ít thời gian hơn cho việc tìm ra cách chơi và nhiều thời gian hơn cho việc quyết định nên xây dựng gì. @NewtonProtocol $LAB $NEWT #Newt

Sau TGE sắp tới, token $GRVT sẽ có nhiều nguồn cầu hơn. Người dùng có thể stake $GRVT để mở khóa Membership và nhận thêm các lợi ích trên sàn GRVT cũng như hệ sinh thái của nó. Điều đó không có gì bất ngờ. Điểm khiến tôi chú ý là một nguồn cầu token khá phổ biến mà, ít nhất là hiện tại, dường như không nằm trong thiết kế của GRVT. Dùng $GRVT để thanh toán phí giao dịch. Nếu người dùng phải trả phí giao dịch bằng $GRVT, thì mỗi lệnh giao dịch tự nhiên sẽ tạo thêm nhu cầu cho token. Nhưng điều đó sẽ kéo theo một chi phí khác đối với người dùng. Người ta không chỉ muốn phí giao dịch thấp. Họ còn muốn chi phí giao dịch luôn có thể dự đoán được, để việc tính PnL, đối soát các lệnh và theo dõi hiệu suất vẫn được thực hiện đơn giản. Khi phí giao dịch được thanh toán bằng một token có giá thay đổi liên tục, nó sẽ không còn là một khoản chi phí cố định nữa. Mỗi lần người dùng tính PnL của mình hoặc đối soát lịch sử giao dịch, họ cũng phải tính đến giá trị của $GRVT tại thời điểm mỗi khoản phí được thanh toán. Và nếu họ giữ một số dư $GRVT riêng chỉ để trả phí giao dịch, thì số dư đó lại tự tạo ra lãi/lỗ riêng, tách biệt với chiến lược giao dịch thực sự. Vì vậy, GRVT hoàn toàn có thể tạo thêm một nguồn cầu cho token của mình, nhưng chi phí cuối cùng sẽ được phản ánh thông qua trải nghiệm người dùng. Thay vào đó, có vẻ GRVT sẵn sàng để “khoảng trống” đó trong nguồn cầu. Lựa chọn này thể hiện kỷ luật Token lấy Người dùng làm trung tâm (User-First Token Discipline) của GRVT. Thay vì đẩy sự biến động của chính token vào phí giao dịch để tạo thêm nhu cầu, GRVT cho phép phí giao dịch chỉ đơn giản là phí giao dịch, trong khi PnL phản ánh hiệu suất của chính các lệnh giao dịch. Người dùng không cần phải tách biệt tác động của biến động giá $GRVT khỏi kết quả thực tế của chiến lược giao dịch chỉ để hiểu họ đã giao dịch tốt đến mức nào. Câu hỏi thực sự sẽ đến sau đó. Khi ngày càng nhiều $GRVT được đưa vào lưu thông và áp lực phải tạo đủ cầu để hấp thụ các đợt mở khóa token trong tương lai tăng lên, liệu GRVT có vẫn đặt trải nghiệm người dùng lên hàng đầu và giữ vững đúng “kỷ luật Token lấy Người dùng làm trung tâm” của GRVT không? Hay @grvt_io sẽ việc mở rộng nhu cầu token cuối cùng được ưu tiên hơn? $SKHYNIX #grvt

Đã xác minh

Sau TGE sắp tới, token $GRVT sẽ có nhiều nguồn cầu hơn.
Người dùng có thể stake $GRVT để mở khóa Membership và nhận thêm các lợi ích trên sàn GRVT cũng như hệ sinh thái của nó.
Điều đó không có gì bất ngờ.
Điểm khiến tôi chú ý là một nguồn cầu token khá phổ biến mà, ít nhất là hiện tại, dường như không nằm trong thiết kế của GRVT.
Dùng $GRVT để thanh toán phí giao dịch.
Nếu người dùng phải trả phí giao dịch bằng $GRVT, thì mỗi lệnh giao dịch tự nhiên sẽ tạo thêm nhu cầu cho token.
Nhưng điều đó sẽ kéo theo một chi phí khác đối với người dùng.
Người ta không chỉ muốn phí giao dịch thấp. Họ còn muốn chi phí giao dịch luôn có thể dự đoán được, để việc tính PnL, đối soát các lệnh và theo dõi hiệu suất vẫn được thực hiện đơn giản.
Khi phí giao dịch được thanh toán bằng một token có giá thay đổi liên tục, nó sẽ không còn là một khoản chi phí cố định nữa.
Mỗi lần người dùng tính PnL của mình hoặc đối soát lịch sử giao dịch, họ cũng phải tính đến giá trị của $GRVT tại thời điểm mỗi khoản phí được thanh toán.
Và nếu họ giữ một số dư $GRVT riêng chỉ để trả phí giao dịch, thì số dư đó lại tự tạo ra lãi/lỗ riêng, tách biệt với chiến lược giao dịch thực sự.
Vì vậy, GRVT hoàn toàn có thể tạo thêm một nguồn cầu cho token của mình, nhưng chi phí cuối cùng sẽ được phản ánh thông qua trải nghiệm người dùng.
Thay vào đó, có vẻ GRVT sẵn sàng để “khoảng trống” đó trong nguồn cầu.
Lựa chọn này thể hiện kỷ luật Token lấy Người dùng làm trung tâm (User-First Token Discipline) của GRVT.
Thay vì đẩy sự biến động của chính token vào phí giao dịch để tạo thêm nhu cầu, GRVT cho phép phí giao dịch chỉ đơn giản là phí giao dịch, trong khi PnL phản ánh hiệu suất của chính các lệnh giao dịch.
Người dùng không cần phải tách biệt tác động của biến động giá $GRVT khỏi kết quả thực tế của chiến lược giao dịch chỉ để hiểu họ đã giao dịch tốt đến mức nào.
Câu hỏi thực sự sẽ đến sau đó.
Khi ngày càng nhiều $GRVT được đưa vào lưu thông và áp lực phải tạo đủ cầu để hấp thụ các đợt mở khóa token trong tương lai tăng lên, liệu GRVT có vẫn đặt trải nghiệm người dùng lên hàng đầu và giữ vững đúng “kỷ luật Token lấy Người dùng làm trung tâm” của GRVT không?
Hay @grvt_io sẽ việc mở rộng nhu cầu token cuối cùng được ưu tiên hơn?
$SKHYNIX #grvt

SKHYNIX+1,48%

Trong khi xem qua tài liệu của Newton Protocol, tôi thấy mình đang tìm kiếm những con số thường dùng để mô tả một giao thức crypto. TVL. TPS. Biểu đồ benchmark. Thật bất ngờ là chúng hầu như không được nhắc đến. Phần lớn tài liệu tập trung vào chính sách, mô phỏng, oracle dữ liệu, triển khai và ủy quyền. Ý nghĩ đầu tiên của tôi là đơn giản: có lẽ những con số đó hiện tại chưa đáng để nổi bật. Nhưng sau khi đọc thêm, tôi bắt đầu tự hỏi liệu việc không đưa chúng vào có phải là một lựa chọn có chủ đích hay không. Khi một giao thức cung cấp cho thị trường một chỉ số “headline” (chỉ số nổi bật), con số đó hiếm khi chỉ còn là một chỉ số. Nó trở thành thấu kính mà mọi người dùng để đánh giá tiến độ. Các nhà phát triển bắt đầu tối ưu cho nó. Cộng đồng bám theo nó. Các so sánh tự nhiên xoay quanh nó. Chẳng bao lâu, các quyết định về sản phẩm bắt đầu lệch về việc cải thiện đúng một con số đó, vì nó đã trở thành cách dễ nhất để chứng minh thành công. Chính điều đó khiến tôi nghĩ về “Measurement Lock-in” (bị khóa vào cách đo lường). Một chỉ số vốn được tạo ra để đo lường tiến bộ. Nhưng theo thời gian, nó cũng có thể bắt đầu định hình tiến bộ đó. Giao thức càng sớm “neo” mình vào một bảng điểm, thì càng khó để biện minh cho những khoản đầu tư không làm tăng ngay chỉ số đó, ngay cả khi chúng khiến kiến trúc vững mạnh hơn về lâu dài. Newton Protocol, ngược lại, vẫn đang xây dựng một lớp policy (chính sách) có thể lập trình, về sau có thể hỗ trợ các tác nhân AI, ví, vault (kho tiền), RWA, và những use case (trường hợp sử dụng) mà hiện chưa thực sự xuất hiện đầy đủ. Ở giai đoạn này, @NewtonProtocol giữ được sự linh hoạt có thể quan trọng hơn việc chỉ cần chứng minh hiệu năng. Khi thị trường bắt đầu đánh giá một giao thức chỉ qua một KPI (chỉ số hiệu suất chính), thì mọi quyết định trong lộ trình gần như không thể tránh khỏi việc bị kéo về hướng cải thiện KPI đó. Điều bắt đầu như một cách mô tả giao thức có thể dần dần trở thành một ràng buộc đối với cách giao thức phát triển. Có lẽ vì thế mà những thiếu vắng trong các số liệu lại nổi bật với tôi. Nếu Newton cố tình tránh Measurement Lock-in, thì có thể câu hỏi thú vị hơn không phải là “Vì sao Newton không công bố nhiều số liệu hơn?” mà là “Giao thức kiểu gì vẫn còn quá sớm để để một chỉ số đơn lẻ định nghĩa thế nào là thành công?” $NEWT $DEXE #Newt

Trong khi xem qua tài liệu của Newton Protocol, tôi thấy mình đang tìm kiếm những con số thường dùng để mô tả một giao thức crypto.
TVL. TPS. Biểu đồ benchmark.
Thật bất ngờ là chúng hầu như không được nhắc đến. Phần lớn tài liệu tập trung vào chính sách, mô phỏng, oracle dữ liệu, triển khai và ủy quyền.
Ý nghĩ đầu tiên của tôi là đơn giản: có lẽ những con số đó hiện tại chưa đáng để nổi bật.
Nhưng sau khi đọc thêm, tôi bắt đầu tự hỏi liệu việc không đưa chúng vào có phải là một lựa chọn có chủ đích hay không.
Khi một giao thức cung cấp cho thị trường một chỉ số “headline” (chỉ số nổi bật), con số đó hiếm khi chỉ còn là một chỉ số. Nó trở thành thấu kính mà mọi người dùng để đánh giá tiến độ. Các nhà phát triển bắt đầu tối ưu cho nó. Cộng đồng bám theo nó. Các so sánh tự nhiên xoay quanh nó. Chẳng bao lâu, các quyết định về sản phẩm bắt đầu lệch về việc cải thiện đúng một con số đó, vì nó đã trở thành cách dễ nhất để chứng minh thành công.
Chính điều đó khiến tôi nghĩ về “Measurement Lock-in” (bị khóa vào cách đo lường).
Một chỉ số vốn được tạo ra để đo lường tiến bộ. Nhưng theo thời gian, nó cũng có thể bắt đầu định hình tiến bộ đó. Giao thức càng sớm “neo” mình vào một bảng điểm, thì càng khó để biện minh cho những khoản đầu tư không làm tăng ngay chỉ số đó, ngay cả khi chúng khiến kiến trúc vững mạnh hơn về lâu dài.
Newton Protocol, ngược lại, vẫn đang xây dựng một lớp policy (chính sách) có thể lập trình, về sau có thể hỗ trợ các tác nhân AI, ví, vault (kho tiền), RWA, và những use case (trường hợp sử dụng) mà hiện chưa thực sự xuất hiện đầy đủ. Ở giai đoạn này, @NewtonProtocol giữ được sự linh hoạt có thể quan trọng hơn việc chỉ cần chứng minh hiệu năng. Khi thị trường bắt đầu đánh giá một giao thức chỉ qua một KPI (chỉ số hiệu suất chính), thì mọi quyết định trong lộ trình gần như không thể tránh khỏi việc bị kéo về hướng cải thiện KPI đó. Điều bắt đầu như một cách mô tả giao thức có thể dần dần trở thành một ràng buộc đối với cách giao thức phát triển.
Có lẽ vì thế mà những thiếu vắng trong các số liệu lại nổi bật với tôi. Nếu Newton cố tình tránh Measurement Lock-in, thì có thể câu hỏi thú vị hơn không phải là “Vì sao Newton không công bố nhiều số liệu hơn?” mà là “Giao thức kiểu gì vẫn còn quá sớm để để một chỉ số đơn lẻ định nghĩa thế nào là thành công?”
$NEWT $DEXE #Newt

DEXE-1,91%

Có phải Newton Protocol đang từ bỏ cuộc đua Performance?Cuối tuần trước mình ghé một quán Pizza Hut ở C3, West Bay Tower. Lúc gọi món, mình để ý menu không hề ghi quán có thể phục vụ bao nhiêu chiếc pizza mỗi giờ, một chiếc mất bao nhiêu phút để nướng hay căn bếp hoạt động nhanh đến mức nào. Thay vào đó, gần như toàn bộ menu chỉ tập trung vào một việc: mình có thể tạo ra chiếc pizza theo bao nhiêu cách khác nhau. Chọn đế mỏng hay dày, thêm phô mai, đổi sốt, bỏ hành, thêm thịt xông khói, đổi kích cỡ... Mỗi lựa chọn mới lại tạo ra thêm một cách kết hợp khác. Lúc đó mình chợt nghĩ, có những hệ thống không cạnh tranh bằng việc làm mọi thứ nhanh hơn. Chúng cạnh tranh bằng việc cho người dùng diễn tả được nhiều lựa chọn hơn. Đến khi đọc docs của Newton Protocol, cảm giác đó lại xuất hiện. Mình đi tìm những con số mà hầu hết các protocol đều rất thích công bố. TVL bao nhiêu. TPS đạt mức nào. Có bao nhiêu validator, bao nhiêu developer, bao nhiêu Policy đang chạy hay benchmark nhanh hơn hệ thống nào. Nhưng càng tìm, mình càng nhận ra một điều khá lạ. Newton Protocol gần như không xây narrative của mình quanh những chỉ số đó. Thay vào đó, phần lớn tài liệu lại dành để giải thích cách viết Policy, cách kết hợp nhiều Data Oracle, cách mô phỏng trước khi deploy, cách tổ chức Policy Packs hay cách Policy được đánh giá trước mỗi transaction. Ban đầu mình nghĩ đó chỉ là khác biệt trong cách viết docs. Nhưng càng đọc, mình càng thấy sự khác biệt nằm ở thứ Newton Protocol đang cố tối ưu. Performance thường trả lời một câu hỏi khá trực tiếp: hệ thống xử lý được bao nhiêu giao dịch, nhanh đến mức nào hay mở rộng tới đâu. Những con số đó phản ánh năng lực xử lý của protocol. Trong khi đó, gần như toàn bộ tài liệu của Newton lại xoay quanh một câu hỏi khác: protocol có thể mô tả được bao nhiêu loại decision. Developer có thể giới hạn theo giá trị giao dịch, theo contract, theo function, theo thời gian, theo tần suất, theo dữ liệu từ nhiều Oracle, rồi tiếp tục kết hợp tất cả chúng trong cùng một Policy. Điều Newton liên tục mở rộng không phải tốc độ thực thi, mà là không gian biểu đạt của decision. Theo mình, đây là lúc Newton Protocol bắt đầu ưu tiên Expressiveness hơn Performance. Điều thú vị là hai hướng tối ưu này dẫn tới hai cách phát triển rất khác nhau. Nếu cạnh tranh bằng Performance, mỗi thế hệ mới của protocol sẽ phải chứng minh mình nhanh hơn, rẻ hơn hoặc xử lý được nhiều transaction hơn thế hệ trước. Đó là một cuộc đua mà mỗi bước tiến đều nhanh chóng trở thành tiêu chuẩn mới của toàn ngành. Nhưng nếu cạnh tranh bằng Expressiveness, câu hỏi lại đổi khác. Không còn là "xử lý bao nhiêu transaction", mà là "có thêm bao nhiêu loại decision mà trước đây chưa thể mô tả". Giá trị của protocol không chỉ đến từ năng lực thực thi, mà từ khả năng biểu đạt ngày càng nhiều quy tắc của thế giới thực thành Policy. Đó cũng là lý do mình thấy Newton Protocol đầu tư rất nhiều vào Rego, Data Oracle, Policy Packs, Simulation hay CLI. Những thành phần này không trực tiếp làm transaction nhanh hơn. Chúng mở rộng số lượng ý tưởng mà developer có thể diễn đạt trước khi transaction được phép xảy ra. Tất nhiên, đây cũng là một lựa chọn có đánh đổi. Một protocol đặt Performance lên hàng đầu thường rất dễ được so sánh. TPS, latency hay throughput đều có thể đặt cạnh đối thủ trong cùng một bảng benchmark. Người dùng cũng dễ hiểu tại sao một hệ thống được xem là tốt hơn. Còn khi ưu tiên Expressiveness, lợi thế lại khó đo lường hơn nhiều. Không có một benchmark đơn giản nào cho khả năng biểu đạt của decision. Giá trị của protocol chỉ thực sự xuất hiện khi developer bắt đầu gặp những bài toán mà các rule đơn giản không còn đủ để mô tả. Có lẽ đó chính là trade-off mà Newton Protocol đang chấp nhận. @NewtonProtocol từ bỏ một cuộc cạnh tranh mà kết quả có thể được chứng minh bằng vài con số quen thuộc, để theo đuổi một hướng mà lợi thế chỉ bộc lộ khi hệ thống phải diễn tả ngày càng nhiều loại decision phức tạp của thế giới thực. $EVAA $NEWT #Newt

Đã xác minh

Bài viết

Có phải Newton Protocol đang từ bỏ cuộc đua Performance?

Cuối tuần trước mình ghé một quán Pizza Hut ở C3, West Bay Tower.
Lúc gọi món, mình để ý menu không hề ghi quán có thể phục vụ bao nhiêu chiếc pizza mỗi giờ, một chiếc mất bao nhiêu phút để nướng hay căn bếp hoạt động nhanh đến mức nào. Thay vào đó, gần như toàn bộ menu chỉ tập trung vào một việc: mình có thể tạo ra chiếc pizza theo bao nhiêu cách khác nhau. Chọn đế mỏng hay dày, thêm phô mai, đổi sốt, bỏ hành, thêm thịt xông khói, đổi kích cỡ... Mỗi lựa chọn mới lại tạo ra thêm một cách kết hợp khác.
Lúc đó mình chợt nghĩ, có những hệ thống không cạnh tranh bằng việc làm mọi thứ nhanh hơn. Chúng cạnh tranh bằng việc cho người dùng diễn tả được nhiều lựa chọn hơn.
Đến khi đọc docs của Newton Protocol, cảm giác đó lại xuất hiện.
Mình đi tìm những con số mà hầu hết các protocol đều rất thích công bố.
TVL bao nhiêu. TPS đạt mức nào. Có bao nhiêu validator, bao nhiêu developer, bao nhiêu Policy đang chạy hay benchmark nhanh hơn hệ thống nào.
Nhưng càng tìm, mình càng nhận ra một điều khá lạ. Newton Protocol gần như không xây narrative của mình quanh những chỉ số đó. Thay vào đó, phần lớn tài liệu lại dành để giải thích cách viết Policy, cách kết hợp nhiều Data Oracle, cách mô phỏng trước khi deploy, cách tổ chức Policy Packs hay cách Policy được đánh giá trước mỗi transaction.
Ban đầu mình nghĩ đó chỉ là khác biệt trong cách viết docs.
Nhưng càng đọc, mình càng thấy sự khác biệt nằm ở thứ Newton Protocol đang cố tối ưu.
Performance thường trả lời một câu hỏi khá trực tiếp: hệ thống xử lý được bao nhiêu giao dịch, nhanh đến mức nào hay mở rộng tới đâu. Những con số đó phản ánh năng lực xử lý của protocol.
Trong khi đó, gần như toàn bộ tài liệu của Newton lại xoay quanh một câu hỏi khác: protocol có thể mô tả được bao nhiêu loại decision.
Developer có thể giới hạn theo giá trị giao dịch, theo contract, theo function, theo thời gian, theo tần suất, theo dữ liệu từ nhiều Oracle, rồi tiếp tục kết hợp tất cả chúng trong cùng một Policy. Điều Newton liên tục mở rộng không phải tốc độ thực thi, mà là không gian biểu đạt của decision.
Theo mình, đây là lúc Newton Protocol bắt đầu ưu tiên Expressiveness hơn Performance.
Điều thú vị là hai hướng tối ưu này dẫn tới hai cách phát triển rất khác nhau.
Nếu cạnh tranh bằng Performance, mỗi thế hệ mới của protocol sẽ phải chứng minh mình nhanh hơn, rẻ hơn hoặc xử lý được nhiều transaction hơn thế hệ trước. Đó là một cuộc đua mà mỗi bước tiến đều nhanh chóng trở thành tiêu chuẩn mới của toàn ngành.
Nhưng nếu cạnh tranh bằng Expressiveness, câu hỏi lại đổi khác. Không còn là "xử lý bao nhiêu transaction", mà là "có thêm bao nhiêu loại decision mà trước đây chưa thể mô tả". Giá trị của protocol không chỉ đến từ năng lực thực thi, mà từ khả năng biểu đạt ngày càng nhiều quy tắc của thế giới thực thành Policy.
Đó cũng là lý do mình thấy Newton Protocol đầu tư rất nhiều vào Rego, Data Oracle, Policy Packs, Simulation hay CLI. Những thành phần này không trực tiếp làm transaction nhanh hơn. Chúng mở rộng số lượng ý tưởng mà developer có thể diễn đạt trước khi transaction được phép xảy ra.
Tất nhiên, đây cũng là một lựa chọn có đánh đổi.
Một protocol đặt Performance lên hàng đầu thường rất dễ được so sánh. TPS, latency hay throughput đều có thể đặt cạnh đối thủ trong cùng một bảng benchmark. Người dùng cũng dễ hiểu tại sao một hệ thống được xem là tốt hơn.
Còn khi ưu tiên Expressiveness, lợi thế lại khó đo lường hơn nhiều. Không có một benchmark đơn giản nào cho khả năng biểu đạt của decision. Giá trị của protocol chỉ thực sự xuất hiện khi developer bắt đầu gặp những bài toán mà các rule đơn giản không còn đủ để mô tả.
Có lẽ đó chính là trade-off mà Newton Protocol đang chấp nhận. @NewtonProtocol từ bỏ một cuộc cạnh tranh mà kết quả có thể được chứng minh bằng vài con số quen thuộc, để theo đuổi một hướng mà lợi thế chỉ bộc lộ khi hệ thống phải diễn tả ngày càng nhiều loại decision phức tạp của thế giới thực.
$EVAA $NEWT #Newt

Lần đầu tiên tôi nạp USDT vào sàn GRVT, tôi đã mở danh sách các chain được hỗ trợ. Có Solana ở đó. Có BNB Chain. Có Tron. Nhưng không có Plasma. Thật sự tôi đã bất ngờ. Plasma được xây dựng với mục tiêu hướng đến stablecoin, đặc biệt là USDT. Vì GRVT đã hỗ trợ hầu hết các chain lớn nơi thanh khoản tập trung, việc thấy Plasma vắng mặt khiến tôi nghĩ rằng họ có thể đang bỏ qua một nguồn vốn quan trọng. Nhìn sâu hơn màn hình nạp tiền, tôi nhận ra đây không chỉ đơn giản là thêm hoặc loại bỏ một chain khác. Mỗi chain mới đồng nghĩa với một ví bổ sung, nhiều hạ tầng hơn, giám sát nhiều hơn, thêm nhiều vận hành hơn và tăng diện tích bề mặt bảo mật cần duy trì. Hỗ trợ thêm một chain không chỉ mở rộng lựa chọn nạp tiền. Nó cũng mở rộng hạ tầng mà GRVT phải vận hành theo thời gian. Chính lúc đó tôi mới nhìn lại các chain đã có trong danh sách. Solana, BNB Chain và Tron đều là các hệ sinh thái nơi hoạt động giao dịch và thanh khoản DeFi đã được thiết lập sâu rộng. Sau một lần nạp, vốn từ các chain đó có khả năng tiếp tục chảy vào hoạt động giao dịch trên GRVT. Còn Plasma, mặt khác, được thiết kế xoay quanh các khoản thanh toán bằng stablecoin. Điều đó không có nghĩa là vốn trên Plasma không thể trở thành vốn giao dịch, nhưng nó đồng nghĩa với việc GRVT cần cân nhắc liệu hoạt động giao dịch mà nó tạo ra có đủ để biện minh cho chi phí tích hợp và hạ tầng dài hạn cần thiết để hỗ trợ thêm một chain hay không. Xét từ góc nhìn đó, điều mà GRVT có thể đang tối ưu không còn là số lượng các chain được hỗ trợ, mà là Kỷ luật Nhập Vốn (Capital Onboarding Discipline). Mỗi chain mới phải mang lại nhiều hơn chỉ thêm vốn. Nó cũng cần chứng minh rằng phần vốn mà chain đó đưa vào có thể được chuyển đổi thành hoạt động giao dịch, đủ để biện minh cho chi phí vận hành mà GRVT sẵn sàng gánh chịu. Điều tôi sẽ theo dõi là chain tiếp theo mà GRVT chọn để hỗ trợ. Nếu cuối cùng Plasma xuất hiện trong danh sách đó, thứ khiến tôi quan tâm sẽ không phải là việc có thêm một tùy chọn nạp nữa. Mà là việc hiểu được điều gì đã thay đổi để GRVT kết luận rằng vốn từ chain Plasma cuối cùng đã đáp ứng chuẩn Kỷ luật Nhập Vốn của họ. @grvt_io #grvt

Đã xác minh

Lần đầu tiên tôi nạp USDT vào sàn GRVT, tôi đã mở danh sách các chain được hỗ trợ.
Có Solana ở đó. Có BNB Chain. Có Tron.
Nhưng không có Plasma.
Thật sự tôi đã bất ngờ. Plasma được xây dựng với mục tiêu hướng đến stablecoin, đặc biệt là USDT. Vì GRVT đã hỗ trợ hầu hết các chain lớn nơi thanh khoản tập trung, việc thấy Plasma vắng mặt khiến tôi nghĩ rằng họ có thể đang bỏ qua một nguồn vốn quan trọng.
Nhìn sâu hơn màn hình nạp tiền, tôi nhận ra đây không chỉ đơn giản là thêm hoặc loại bỏ một chain khác.
Mỗi chain mới đồng nghĩa với một ví bổ sung, nhiều hạ tầng hơn, giám sát nhiều hơn, thêm nhiều vận hành hơn và tăng diện tích bề mặt bảo mật cần duy trì. Hỗ trợ thêm một chain không chỉ mở rộng lựa chọn nạp tiền. Nó cũng mở rộng hạ tầng mà GRVT phải vận hành theo thời gian.
Chính lúc đó tôi mới nhìn lại các chain đã có trong danh sách.
Solana, BNB Chain và Tron đều là các hệ sinh thái nơi hoạt động giao dịch và thanh khoản DeFi đã được thiết lập sâu rộng. Sau một lần nạp, vốn từ các chain đó có khả năng tiếp tục chảy vào hoạt động giao dịch trên GRVT. Còn Plasma, mặt khác, được thiết kế xoay quanh các khoản thanh toán bằng stablecoin. Điều đó không có nghĩa là vốn trên Plasma không thể trở thành vốn giao dịch, nhưng nó đồng nghĩa với việc GRVT cần cân nhắc liệu hoạt động giao dịch mà nó tạo ra có đủ để biện minh cho chi phí tích hợp và hạ tầng dài hạn cần thiết để hỗ trợ thêm một chain hay không.
Xét từ góc nhìn đó, điều mà GRVT có thể đang tối ưu không còn là số lượng các chain được hỗ trợ, mà là Kỷ luật Nhập Vốn (Capital Onboarding Discipline). Mỗi chain mới phải mang lại nhiều hơn chỉ thêm vốn. Nó cũng cần chứng minh rằng phần vốn mà chain đó đưa vào có thể được chuyển đổi thành hoạt động giao dịch, đủ để biện minh cho chi phí vận hành mà GRVT sẵn sàng gánh chịu.
Điều tôi sẽ theo dõi là chain tiếp theo mà GRVT chọn để hỗ trợ. Nếu cuối cùng Plasma xuất hiện trong danh sách đó, thứ khiến tôi quan tâm sẽ không phải là việc có thêm một tùy chọn nạp nữa. Mà là việc hiểu được điều gì đã thay đổi để GRVT kết luận rằng vốn từ chain Plasma cuối cùng đã đáp ứng chuẩn Kỷ luật Nhập Vốn của họ.
@grvt_io #grvt

BNB+0,30%

SOL+0,98%

Newton Protocol đang tạo ra "shared reality" như thế nào?Tối hôm trước, mình ngồi ăn với một người bạn làm Data Engineer. Câu chuyện bắt đầu từ một vấn đề rất đời thường. Cậu ấy kể có lần dashboard doanh thu của công ty hiển thị ba con số khác nhau. Team Finance mở một dashboard. Team Sales mở dashboard khác. Ban điều hành lại xem một báo cáo tổng hợp. Điều buồn cười là cả ba đều lấy dữ liệu từ cùng một hệ thống. Mình hỏi: "Cuối cùng số nào đúng?" Cậu ấy cười. "Câu hỏi đó thường không quan trọng bằng một câu khác." "Là gì?" "Là cả công ty đang ra quyết định dựa trên cùng một con số hay không." Lúc đó mình thấy hơi lạ. Nếu đã có một con số đúng nhất thì chẳng phải chỉ cần tìm nó là đủ sao? Nhưng càng nghĩ mình càng thấy trong rất nhiều hệ thống, vấn đề không nằm ở việc thiếu dữ liệu. Vấn đề nằm ở việc mỗi người đang nhìn một phiên bản khác nhau của cùng một dữ liệu. Một API cập nhật sớm hơn vài giây. Một node lấy dữ liệu muộn hơn. Một price feed có độ trễ khác. Sai lệch đôi khi rất nhỏ. Nhưng nếu mỗi người đều bắt đầu từ một "reality" khác nhau, thì ngay cả khi tất cả đều làm đúng quy trình, kết quả cuối cùng vẫn có thể khác nhau. Đó cũng là lúc mình nhìn cơ chế Two-Phase Consensus của Newton Protocol theo một hướng khác. Thoạt nhìn, người ta rất dễ nghĩ đây chỉ là cách nhiều operators cùng lấy dữ liệu, Gateway tính median rồi mọi người cùng ký. Nhưng điều làm mình chú ý lại không phải median. Mà là thứ median đang tạo ra. Nó không tạo thêm dữ liệu mới. Nó cũng không cố chứng minh operator nào đúng hơn operator nào. Thay vào đó, nó tạo ra một phiên bản chung của dữ liệu để toàn bộ hệ thống cùng sử dụng trước khi policy được đánh giá. Đây là một khác biệt rất lớn. Thông thường, chúng ta hay nghĩ consensus là quá trình tìm ra sự thật. Nhưng Newton Protocol dường như không theo đuổi mục tiêu đó. Một operator trả về giá 100. Operator khác trả về 101. Người khác nữa trả về 102. Hệ thống không cố truy tìm ai mới là người đúng tuyệt đối. Điều nó cần là mọi operator đều bước vào giai đoạn đánh giá policy với cùng một bộ dữ liệu. Nói cách khác, Newton Protocol không cố tạo ra một "true reality". Họ tạo ra một "shared reality". Lúc đầu mình nghĩ đây chỉ là một chi tiết kỹ thuật. Nhưng càng đẩy tiếp chuỗi suy nghĩ, mình càng thấy nếu không có lớp shared reality này thì toàn bộ policy phía sau cũng mất ý nghĩa. Hãy tưởng tượng cùng một policy viết rằng chỉ cho phép giao dịch khi giá Lab ($LAB )khi giá dưới 0.5 USD. Nếu mỗi operator nhìn thấy một mức giá khác nhau, thì bản thân policy không còn là một quy tắc thống nhất nữa. Một policy. Ba reality. Ba kết quả. Lúc đó, vấn đề không còn nằm ở policy. Vấn đề nằm ở đầu vào của policy. Điều này làm mình nhận ra một thứ khá thú vị. Rất nhiều người xem policy là trung tâm của hệ thống. Nhưng Newton Protocol lại dành hẳn một phase chỉ để xử lý dữ liệu trước khi policy được phép hoạt động. Giống như dự án đang ngầm nói rằng một quyết định tốt không bắt đầu từ một rule tốt. Nó bắt đầu từ việc tất cả cùng nhìn về một reality trước đã. Nhìn từ góc này, Two-Phase Consensus không còn chỉ là một tối ưu về mặt kỹ thuật. Nó phản ánh một thứ tự rất rõ trong cách Newton Protocol xây dựng hạ tầng. Đầu tiên là thống nhất reality. Sau đó mới thống nhất decision. Không phải vì reality tuyệt đối đã được tìm thấy. Mà vì nếu mỗi thành phần vẫn đang sống trong một phiên bản dữ liệu khác nhau, thì mọi consensus phía sau chỉ là sự đồng thuận trên những thế giới khác nhau. Có lẽ đó mới là điều mình thấy đáng chú ý nhất. Newton Protocol không dùng consensus để tạo ra dữ liệu mới. @NewtonProtocol dùng consensus để tạo ra một reality đủ chung, đủ nhất quán và đủ đáng tin để mọi policy phía sau đều đang nói về cùng một thế giới. $NEWT #Newt

Đã xác minh

Bài viết

Newton Protocol đang tạo ra "shared reality" như thế nào?

Tối hôm trước, mình ngồi ăn với một người bạn làm Data Engineer. Câu chuyện bắt đầu từ một vấn đề rất đời thường.
Cậu ấy kể có lần dashboard doanh thu của công ty hiển thị ba con số khác nhau.
Team Finance mở một dashboard.
Team Sales mở dashboard khác.
Ban điều hành lại xem một báo cáo tổng hợp.
Điều buồn cười là cả ba đều lấy dữ liệu từ cùng một hệ thống.
Mình hỏi:
"Cuối cùng số nào đúng?"
Cậu ấy cười.
"Câu hỏi đó thường không quan trọng bằng một câu khác."
"Là gì?"
"Là cả công ty đang ra quyết định dựa trên cùng một con số hay không."
Lúc đó mình thấy hơi lạ.
Nếu đã có một con số đúng nhất thì chẳng phải chỉ cần tìm nó là đủ sao?
Nhưng càng nghĩ mình càng thấy trong rất nhiều hệ thống, vấn đề không nằm ở việc thiếu dữ liệu.
Vấn đề nằm ở việc mỗi người đang nhìn một phiên bản khác nhau của cùng một dữ liệu.
Một API cập nhật sớm hơn vài giây.
Một node lấy dữ liệu muộn hơn.
Một price feed có độ trễ khác.
Sai lệch đôi khi rất nhỏ.
Nhưng nếu mỗi người đều bắt đầu từ một "reality" khác nhau, thì ngay cả khi tất cả đều làm đúng quy trình, kết quả cuối cùng vẫn có thể khác nhau.
Đó cũng là lúc mình nhìn cơ chế Two-Phase Consensus của Newton Protocol theo một hướng khác.
Thoạt nhìn, người ta rất dễ nghĩ đây chỉ là cách nhiều operators cùng lấy dữ liệu, Gateway tính median rồi mọi người cùng ký.
Nhưng điều làm mình chú ý lại không phải median.
Mà là thứ median đang tạo ra.
Nó không tạo thêm dữ liệu mới.
Nó cũng không cố chứng minh operator nào đúng hơn operator nào.
Thay vào đó, nó tạo ra một phiên bản chung của dữ liệu để toàn bộ hệ thống cùng sử dụng trước khi policy được đánh giá.
Đây là một khác biệt rất lớn.
Thông thường, chúng ta hay nghĩ consensus là quá trình tìm ra sự thật.
Nhưng Newton Protocol dường như không theo đuổi mục tiêu đó.
Một operator trả về giá 100.
Operator khác trả về 101.
Người khác nữa trả về 102.
Hệ thống không cố truy tìm ai mới là người đúng tuyệt đối.
Điều nó cần là mọi operator đều bước vào giai đoạn đánh giá policy với cùng một bộ dữ liệu.
Nói cách khác, Newton Protocol không cố tạo ra một "true reality".
Họ tạo ra một "shared reality".
Lúc đầu mình nghĩ đây chỉ là một chi tiết kỹ thuật.
Nhưng càng đẩy tiếp chuỗi suy nghĩ, mình càng thấy nếu không có lớp shared reality này thì toàn bộ policy phía sau cũng mất ý nghĩa.
Hãy tưởng tượng cùng một policy viết rằng chỉ cho phép giao dịch khi giá Lab ($LAB )khi giá dưới 0.5 USD.
Nếu mỗi operator nhìn thấy một mức giá khác nhau, thì bản thân policy không còn là một quy tắc thống nhất nữa.
Một policy.
Ba reality.
Ba kết quả.
Lúc đó, vấn đề không còn nằm ở policy.
Vấn đề nằm ở đầu vào của policy.
Điều này làm mình nhận ra một thứ khá thú vị.
Rất nhiều người xem policy là trung tâm của hệ thống.
Nhưng Newton Protocol lại dành hẳn một phase chỉ để xử lý dữ liệu trước khi policy được phép hoạt động.
Giống như dự án đang ngầm nói rằng một quyết định tốt không bắt đầu từ một rule tốt.
Nó bắt đầu từ việc tất cả cùng nhìn về một reality trước đã.
Nhìn từ góc này, Two-Phase Consensus không còn chỉ là một tối ưu về mặt kỹ thuật.
Nó phản ánh một thứ tự rất rõ trong cách Newton Protocol xây dựng hạ tầng.
Đầu tiên là thống nhất reality.
Sau đó mới thống nhất decision.
Không phải vì reality tuyệt đối đã được tìm thấy.
Mà vì nếu mỗi thành phần vẫn đang sống trong một phiên bản dữ liệu khác nhau, thì mọi consensus phía sau chỉ là sự đồng thuận trên những thế giới khác nhau.
Có lẽ đó mới là điều mình thấy đáng chú ý nhất.
Newton Protocol không dùng consensus để tạo ra dữ liệu mới.
@NewtonProtocol dùng consensus để tạo ra một reality đủ chung, đủ nhất quán và đủ đáng tin để mọi policy phía sau đều đang nói về cùng một thế giới.
$NEWT #Newt

Hầu hết các hệ thống cấp quyền chỉ biết cách trả về một câu trả lời: có hoặc không. Newton Protocol khiến tôi nghĩ về một điều khác biệt. Trong một trong các ví dụ về chính sách của nó, việc vượt quá giới hạn chi tiêu không chỉ tạo ra allow = false. Chính sách cũng có thể trả về một cap, hiển thị giá trị tối đa sẽ được chấp nhận cho cùng một giao dịch. Ban đầu, điều này trông như một chi tiết triển khai nhỏ. Nhưng càng nhìn, tôi càng cảm thấy nó giống như một triết lý cấp quyền khác. Việc từ chối nhị phân kết thúc tương tác. Hệ thống từ chối yêu cầu và để người gọi tự quyết định bước tiếp theo. Việc trả về một ràng buộc thì khác. Thay vì chỉ nói “bạn không thể làm việc này”, chính sách còn tiết lộ ranh giới phân tách hành động có thể chấp nhận với hành động không thể chấp nhận. Sự khác biệt đó có thể không quan trọng lắm đối với phần mềm đơn giản chỉ lặp lại các yêu cầu bị lỗi. Nhưng nó có thể quan trọng rất nhiều đối với các tác nhân AI tự động. Khi các tác nhân ngày càng trở nên mạnh mẽ hơn, việc từ chối không còn chỉ là một lỗi. Nó trở thành phản hồi. Một giới hạn chi tiêu cho tác nhân biết rõ nó đã vượt quá phạm vi cho phép đến mức nào. Thay vì lặp lại cùng một sai lầm hay chờ con người can thiệp, một tác nhân đủ năng lực có thể tạo ra một giao dịch mới vốn đã đáp ứng chính sách. Đó là lý do tôi nghĩ Newton Protocol có thể đang chuẩn bị cho Self-correcting AI Agents. @NewtonProtocol không phải đang cố làm cho các tác nhân AI thông minh hơn. Thay vào đó, nó đang định hình môi trường mà các tác nhân đó tương tác. Các chính sách không còn là các cổng quyền tĩnh nữa mà bắt đầu đóng vai trò như phản hồi có cấu trúc để các tác nhân tự động ngày càng có thể học cách đáp ứng. Điều đó có thể trở thành một thay đổi kiến trúc lớn hơn nhiều so với vẻ bề ngoài ban đầu. Các tác nhân AI ngày nay thường dừng lại khi một chính sách nói “không”. Ngày mai, các tác nhân có thể xem một cap được trả về như hướng dẫn cho lần thử tiếp theo thay vì là điểm dừng của chính giao dịch hiện tại. Nếu điều đó xảy ra, thách thức đối với Newton Protocol sẽ không còn là việc từ chối các giao dịch tệ, mà là thiết kế các đầu ra chính sách như cap để các tác nhân ngày càng năng lực có thể tiếp tục học hỏi từ đó. $NEWT #Newt

Đúng một phần

Hầu hết các hệ thống cấp quyền chỉ biết cách trả về một câu trả lời: có hoặc không.
Newton Protocol khiến tôi nghĩ về một điều khác biệt. Trong một trong các ví dụ về chính sách của nó, việc vượt quá giới hạn chi tiêu không chỉ tạo ra allow = false. Chính sách cũng có thể trả về một cap, hiển thị giá trị tối đa sẽ được chấp nhận cho cùng một giao dịch.
Ban đầu, điều này trông như một chi tiết triển khai nhỏ.
Nhưng càng nhìn, tôi càng cảm thấy nó giống như một triết lý cấp quyền khác.
Việc từ chối nhị phân kết thúc tương tác. Hệ thống từ chối yêu cầu và để người gọi tự quyết định bước tiếp theo. Việc trả về một ràng buộc thì khác. Thay vì chỉ nói “bạn không thể làm việc này”, chính sách còn tiết lộ ranh giới phân tách hành động có thể chấp nhận với hành động không thể chấp nhận.
Sự khác biệt đó có thể không quan trọng lắm đối với phần mềm đơn giản chỉ lặp lại các yêu cầu bị lỗi. Nhưng nó có thể quan trọng rất nhiều đối với các tác nhân AI tự động.
Khi các tác nhân ngày càng trở nên mạnh mẽ hơn, việc từ chối không còn chỉ là một lỗi. Nó trở thành phản hồi. Một giới hạn chi tiêu cho tác nhân biết rõ nó đã vượt quá phạm vi cho phép đến mức nào. Thay vì lặp lại cùng một sai lầm hay chờ con người can thiệp, một tác nhân đủ năng lực có thể tạo ra một giao dịch mới vốn đã đáp ứng chính sách.
Đó là lý do tôi nghĩ Newton Protocol có thể đang chuẩn bị cho Self-correcting AI Agents. @NewtonProtocol không phải đang cố làm cho các tác nhân AI thông minh hơn. Thay vào đó, nó đang định hình môi trường mà các tác nhân đó tương tác. Các chính sách không còn là các cổng quyền tĩnh nữa mà bắt đầu đóng vai trò như phản hồi có cấu trúc để các tác nhân tự động ngày càng có thể học cách đáp ứng.
Điều đó có thể trở thành một thay đổi kiến trúc lớn hơn nhiều so với vẻ bề ngoài ban đầu.
Các tác nhân AI ngày nay thường dừng lại khi một chính sách nói “không”. Ngày mai, các tác nhân có thể xem một cap được trả về như hướng dẫn cho lần thử tiếp theo thay vì là điểm dừng của chính giao dịch hiện tại. Nếu điều đó xảy ra, thách thức đối với Newton Protocol sẽ không còn là việc từ chối các giao dịch tệ, mà là thiết kế các đầu ra chính sách như cap để các tác nhân ngày càng năng lực có thể tiếp tục học hỏi từ đó. $NEWT #Newt

Một chi tiết trong thiết kế WebSocket của GRVT đã thu hút sự chú ý của tôi. sequence_number chỉ có ý nghĩa trong phạm vi của một kết nối WebSocket. Nếu số này nhảy, nó chỉ cho biết rằng kết nối của bạn đã bị bỏ lỡ dữ liệu. Nó không nói gì về bất kỳ client nào khác đang kết nối với GRVT. Điều này trở nên thú vị hơn khi các nhà phát triển xây dựng các công cụ thực thi hoặc hệ thống giao dịch định lượng trên nền tảng các API của GRVT. Mỗi tích hợp đều duy trì trạng thái thị trường riêng của mình. Việc phát hiện thiếu cập nhật, yêu cầu một snapshot mới và quyết định khi nào trạng thái đó còn hợp lệ đều là những trách nhiệm được xử lý bên trong chính tích hợp. GRVT phân phối các sự kiện thị trường, nhưng không quyết định liệu một hệ thống giao dịch có tái tạo đúng trạng thái thị trường hay không. Điều này thay đổi nơi mà trạng thái thị trường được “sở hữu”. Thay vì duy trì một trạng thái chính thống cho mọi hệ thống được kết nối, GRVT để cho từng tích hợp chịu trách nhiệm duy trì trạng thái của riêng nó. Các hệ thống giao dịch khác nhau có thể sử dụng cùng một tập sự kiện thị trường nhưng vẫn duy trì các trạng thái cục bộ khác nhau, vì mỗi hệ thống tuân theo một chính sách khôi phục khác nhau sau khi phát hiện một khoảng trống. Kiến trúc một cách tự nhiên hướng tới mô hình State Ownership (Sở hữu trạng thái). Sở hữu trạng thái thị trường cũng có nghĩa là sở hữu các quyết định kỹ thuật đứng sau nó. Mỗi nhóm có thể tối ưu việc đồng bộ, khôi phục và xác thực theo đúng quy trình của riêng mình thay vì kế thừa một mô hình duy nhất từ sàn giao dịch. GRVT chỉ cần cung cấp các sự kiện thị trường nhất quán. Việc các sự kiện đó trở thành một trạng thái thị trường đáng tin cậy được cố ý để lại cho từng tích hợp. Bằng cách làm cho sequence_number chỉ cục bộ đối với mỗi kết nối WebSocket, GRVT để trạng thái thị trường thuộc về từng tích hợp API thay vì coi đó là một phần của chính sàn giao dịch. Khi ngày càng nhiều hệ thống giao dịch kết nối thông qua các API của GRVT, State Ownership giúp sàn tập trung vào việc phân phối các sự kiện thị trường thay vì mở rộng sang quản lý trạng thái theo từng ứng dụng. Thách thức là tiếp tục phục vụ các luồng giao dịch ngày càng đa dạng mà không dần dần “nắm quyền” vào logic ứng dụng thuộc về từng tích hợp. $LAB @grvt_io #grvt

Đúng một phần

Một chi tiết trong thiết kế WebSocket của GRVT đã thu hút sự chú ý của tôi.
sequence_number chỉ có ý nghĩa trong phạm vi của một kết nối WebSocket. Nếu số này nhảy, nó chỉ cho biết rằng kết nối của bạn đã bị bỏ lỡ dữ liệu. Nó không nói gì về bất kỳ client nào khác đang kết nối với GRVT.
Điều này trở nên thú vị hơn khi các nhà phát triển xây dựng các công cụ thực thi hoặc hệ thống giao dịch định lượng trên nền tảng các API của GRVT.
Mỗi tích hợp đều duy trì trạng thái thị trường riêng của mình. Việc phát hiện thiếu cập nhật, yêu cầu một snapshot mới và quyết định khi nào trạng thái đó còn hợp lệ đều là những trách nhiệm được xử lý bên trong chính tích hợp. GRVT phân phối các sự kiện thị trường, nhưng không quyết định liệu một hệ thống giao dịch có tái tạo đúng trạng thái thị trường hay không.
Điều này thay đổi nơi mà trạng thái thị trường được “sở hữu”.
Thay vì duy trì một trạng thái chính thống cho mọi hệ thống được kết nối, GRVT để cho từng tích hợp chịu trách nhiệm duy trì trạng thái của riêng nó. Các hệ thống giao dịch khác nhau có thể sử dụng cùng một tập sự kiện thị trường nhưng vẫn duy trì các trạng thái cục bộ khác nhau, vì mỗi hệ thống tuân theo một chính sách khôi phục khác nhau sau khi phát hiện một khoảng trống.
Kiến trúc một cách tự nhiên hướng tới mô hình State Ownership (Sở hữu trạng thái).
Sở hữu trạng thái thị trường cũng có nghĩa là sở hữu các quyết định kỹ thuật đứng sau nó. Mỗi nhóm có thể tối ưu việc đồng bộ, khôi phục và xác thực theo đúng quy trình của riêng mình thay vì kế thừa một mô hình duy nhất từ sàn giao dịch. GRVT chỉ cần cung cấp các sự kiện thị trường nhất quán. Việc các sự kiện đó trở thành một trạng thái thị trường đáng tin cậy được cố ý để lại cho từng tích hợp.
Bằng cách làm cho sequence_number chỉ cục bộ đối với mỗi kết nối WebSocket, GRVT để trạng thái thị trường thuộc về từng tích hợp API thay vì coi đó là một phần của chính sàn giao dịch.
Khi ngày càng nhiều hệ thống giao dịch kết nối thông qua các API của GRVT, State Ownership giúp sàn tập trung vào việc phân phối các sự kiện thị trường thay vì mở rộng sang quản lý trạng thái theo từng ứng dụng. Thách thức là tiếp tục phục vụ các luồng giao dịch ngày càng đa dạng mà không dần dần “nắm quyền” vào logic ứng dụng thuộc về từng tích hợp.
$LAB @grvt_io #grvt

Newton Protocol đang trì hoãn permissionless để đổi lấy điều gì?Tối thứ sáu tuần trước, khoảng 7 giờ tối, mình đi ăn lẩu Triều Châu với vài người bạn ở nhà hàng Phan Xích Long trên đường Nguyễn Du. Quán khá đông nên món lên chậm hơn bình thường. Trong lúc đợi, mình hỏi quản lý: Sao anh không nhận thêm khách, nhà hàng mình vẫn còn vài bàn trống cơ mà ? Anh cười rồi trả lời: "Nhận thêm thì được thôi. Nhưng nếu bếp bắt đầu quá tải, món ra chậm, phục vụ rối và chất lượng không còn ổn định. Lúc đó tôi không chỉ mất một bàn khách, mà mất luôn khả năng kiểm soát cả ca phục vụ." Câu trả lời đó làm mình nhớ đến vấn đề Deploying with CLI của Newton Protocol. Trước khi một Policy có thể được sử dụng trên mainnet, developer cần được allowlist bởi đội ngũ @NewtonProtocol . Chỉ sau bước đó, Policy mới được đưa vào môi trường chính thức. Phản ứng đầu tiên của mình là khá bất ngờ. Một protocol đang xây dựng một ecosystem mở lại chủ động đặt thêm một lớp kiểm soát trước mainnet. Điều này nghe có vẻ đi ngược với cách nhiều protocol cố gắng mở cửa càng sớm càng tốt. Nhưng càng nghĩ, mình càng thấy Newton Protocol dường như đang cố tránh một loại chi phí khác. Mỗi Policy mới không chỉ bổ sung thêm một use case. Nó còn bổ sung thêm một hành vi mà protocol phải quan sát, một tập giả định cần được kiểm chứng và một cách sử dụng mới cần được hiểu. Nếu số lượng Policies tăng nhanh hơn khả năng theo dõi của hệ thống, phần chưa được hiểu rõ cũng sẽ tích lũy theo thời gian. Đó cũng là lúc Control Debt bắt đầu xuất hiện. Khác với Technical Debt, Control Debt không đến từ code. Nó xuất hiện khi tốc độ mở rộng vượt quá khả năng kiểm soát của đội ngũ vận hành. Ban đầu điều đó có thể chưa tạo ra vấn đề rõ ràng. Nhưng khi hệ thống ngày càng lớn, chất lượng của mỗi lần can thiệp cũng bắt đầu thay đổi. Một vấn đề phát sinh sẽ ngày càng khó lần ngược về đúng Policy, đúng tương tác hay đúng giả định đã gây ra nó. Mỗi lần điều chỉnh vì thế mang theo nhiều bất định hơn, còn chi phí để xác nhận mình đã sửa đúng vấn đề cũng tiếp tục tăng. Nhìn theo góc đó, allowlist không chỉ là một cơ chế giới hạn quyền tham gia. Nó còn là cách Newton giữ cho Control Debt không tăng nhanh hơn năng lực vận hành của chính mình. Dự án chấp nhận làm chậm tốc độ mở rộng trong giai đoạn đầu để mỗi Policy mới vẫn nằm trong phạm vi có thể quan sát, hiểu và can thiệp với mức độ chắc chắn đủ cao. Điều mình thấy đáng theo dõi là Control Debt không phải thứ có thể loại bỏ hoàn toàn. Nếu Newton Protocol tiếp tục mở rộng, builder, Policies và các integration sẽ ngày càng nhiều. Khi đó, câu hỏi sẽ không còn là bao giờ allowlist được gỡ bỏ, mà là Newton sẽ xây thêm những cơ chế nào để chất lượng của mỗi lần can thiệp không giảm đi ngay cả khi quy mô của toàn bộ ecosystem vẫn tiếp tục tăng. $LAB $NEWT #Newt

Đã xác minh

Bài viết

Newton Protocol đang trì hoãn permissionless để đổi lấy điều gì?

Tối thứ sáu tuần trước, khoảng 7 giờ tối, mình đi ăn lẩu Triều Châu với vài người bạn ở nhà hàng Phan Xích Long trên đường Nguyễn Du. Quán khá đông nên món lên chậm hơn bình thường.
Trong lúc đợi, mình hỏi quản lý: Sao anh không nhận thêm khách, nhà hàng mình vẫn còn vài bàn trống cơ mà ?
Anh cười rồi trả lời:
"Nhận thêm thì được thôi. Nhưng nếu bếp bắt đầu quá tải, món ra chậm, phục vụ rối và chất lượng không còn ổn định. Lúc đó tôi không chỉ mất một bàn khách, mà mất luôn khả năng kiểm soát cả ca phục vụ."
Câu trả lời đó làm mình nhớ đến vấn đề Deploying with CLI của Newton Protocol.
Trước khi một Policy có thể được sử dụng trên mainnet, developer cần được allowlist bởi đội ngũ @NewtonProtocol . Chỉ sau bước đó, Policy mới được đưa vào môi trường chính thức.
Phản ứng đầu tiên của mình là khá bất ngờ.
Một protocol đang xây dựng một ecosystem mở lại chủ động đặt thêm một lớp kiểm soát trước mainnet. Điều này nghe có vẻ đi ngược với cách nhiều protocol cố gắng mở cửa càng sớm càng tốt.
Nhưng càng nghĩ, mình càng thấy Newton Protocol dường như đang cố tránh một loại chi phí khác.
Mỗi Policy mới không chỉ bổ sung thêm một use case. Nó còn bổ sung thêm một hành vi mà protocol phải quan sát, một tập giả định cần được kiểm chứng và một cách sử dụng mới cần được hiểu. Nếu số lượng Policies tăng nhanh hơn khả năng theo dõi của hệ thống, phần chưa được hiểu rõ cũng sẽ tích lũy theo thời gian.
Đó cũng là lúc Control Debt bắt đầu xuất hiện.
Khác với Technical Debt, Control Debt không đến từ code. Nó xuất hiện khi tốc độ mở rộng vượt quá khả năng kiểm soát của đội ngũ vận hành. Ban đầu điều đó có thể chưa tạo ra vấn đề rõ ràng. Nhưng khi hệ thống ngày càng lớn, chất lượng của mỗi lần can thiệp cũng bắt đầu thay đổi. Một vấn đề phát sinh sẽ ngày càng khó lần ngược về đúng Policy, đúng tương tác hay đúng giả định đã gây ra nó. Mỗi lần điều chỉnh vì thế mang theo nhiều bất định hơn, còn chi phí để xác nhận mình đã sửa đúng vấn đề cũng tiếp tục tăng.
Nhìn theo góc đó, allowlist không chỉ là một cơ chế giới hạn quyền tham gia. Nó còn là cách Newton giữ cho Control Debt không tăng nhanh hơn năng lực vận hành của chính mình. Dự án chấp nhận làm chậm tốc độ mở rộng trong giai đoạn đầu để mỗi Policy mới vẫn nằm trong phạm vi có thể quan sát, hiểu và can thiệp với mức độ chắc chắn đủ cao.
Điều mình thấy đáng theo dõi là Control Debt không phải thứ có thể loại bỏ hoàn toàn. Nếu Newton Protocol tiếp tục mở rộng, builder, Policies và các integration sẽ ngày càng nhiều. Khi đó, câu hỏi sẽ không còn là bao giờ allowlist được gỡ bỏ, mà là Newton sẽ xây thêm những cơ chế nào để chất lượng của mỗi lần can thiệp không giảm đi ngay cả khi quy mô của toàn bộ ecosystem vẫn tiếp tục tăng.
$LAB $NEWT #Newt

Khi deploy một Policy bằng CLI trên Newton Protocol, policy_params cuối cùng phải được chuyển thành Flat JSON đúng với params_schema.json. Nếu giữ nguyên Nested JSON, quá trình Schema Validation sẽ thất bại và Policy sẽ không thể pass evaluation. Điều làm mình chú ý là CLI vẫn làm việc với Nested JSON trong suốt workflow. Chỉ đến khi Policy được evaluate, toàn bộ data mới buộc phải xuất hiện dưới dạng Flat JSON. Theo mình, đây không phải là một quy định dành cho CLI. Nó là một quy định dành cho Policy layer. Trước khi đi vào Policy, mọi representation đều phải được chuyển về cùng một hình thức. Translation cost vẫn tồn tại, nhưng chỉ xuất hiện tại boundary của system. Sau điểm đó, Policy không còn cần biết data đến từ CLI hay bất kỳ integration nào khác. Điều duy nhất còn lại là data có khớp với schema đã công bố hay không. Đó cũng là lúc Serialization Neutrality bắt đầu hình thành. Điều được giữ trung lập không phải cách mỗi tool serialize data, mà là cách Policy tiếp nhận data. Mọi representation differences đều phải được loại bỏ trước khi evaluation bắt đầu. Vì vậy, mỗi integration mới chỉ cần tự xử lý serialization của mình, thay vì buộc Policy layer phải thích nghi với thêm một representation mới. Lúc này, thách thức của Newton Protocol không nằm ở việc hỗ trợ thêm nhiều tools. Thách thức nằm ở việc tiếp tục giữ được Serialization Neutrality khi ecosystem mở rộng. Chỉ cần một integration được phép vượt qua boundary với một representation riêng, Policy layer sẽ dần phải hiểu nhiều representations khác nhau và chính Serialization Neutrality cũng sẽ mất đi ý nghĩa ban đầu. $B $BEAT $NEWT #Newt @NewtonProtocol

Đúng một phần

Khi deploy một Policy bằng CLI trên Newton Protocol, policy_params cuối cùng phải được chuyển thành Flat JSON đúng với params_schema.json. Nếu giữ nguyên Nested JSON, quá trình Schema Validation sẽ thất bại và Policy sẽ không thể pass evaluation.
Điều làm mình chú ý là CLI vẫn làm việc với Nested JSON trong suốt workflow. Chỉ đến khi Policy được evaluate, toàn bộ data mới buộc phải xuất hiện dưới dạng Flat JSON.
Theo mình, đây không phải là một quy định dành cho CLI. Nó là một quy định dành cho Policy layer.
Trước khi đi vào Policy, mọi representation đều phải được chuyển về cùng một hình thức. Translation cost vẫn tồn tại, nhưng chỉ xuất hiện tại boundary của system. Sau điểm đó, Policy không còn cần biết data đến từ CLI hay bất kỳ integration nào khác. Điều duy nhất còn lại là data có khớp với schema đã công bố hay không.
Đó cũng là lúc Serialization Neutrality bắt đầu hình thành.
Điều được giữ trung lập không phải cách mỗi tool serialize data, mà là cách Policy tiếp nhận data. Mọi representation differences đều phải được loại bỏ trước khi evaluation bắt đầu. Vì vậy, mỗi integration mới chỉ cần tự xử lý serialization của mình, thay vì buộc Policy layer phải thích nghi với thêm một representation mới.
Lúc này, thách thức của Newton Protocol không nằm ở việc hỗ trợ thêm nhiều tools. Thách thức nằm ở việc tiếp tục giữ được Serialization Neutrality khi ecosystem mở rộng. Chỉ cần một integration được phép vượt qua boundary với một representation riêng, Policy layer sẽ dần phải hiểu nhiều representations khác nhau và chính Serialization Neutrality cũng sẽ mất đi ý nghĩa ban đầu.
$B $BEAT $NEWT #Newt @NewtonProtocol

Vài ngày trước, tôi nhận thấy một chi tiết thú vị khi khám phá GRVT. Các khóa API khác nhau có thể được gán các quyền khác nhau. Một số được phép đặt lệnh. Một số khác có thể chuyển tài sản. Một số thì bị giới hạn ở quyền chỉ đọc. Không có khóa nào được kỳ vọng sẽ làm được mọi thứ. Thay vì coi quyền truy cập như một tính năng tiện lợi, GRVT sử dụng chúng để phân tách thẩm quyền trước khi bất kỳ thao tác nào bắt đầu. Mọi khả năng mới trên GRVT không tự động trở nên sẵn dùng cho mọi khóa API. Giao dịch, nạp tiền, rút tiền và quản lý tài khoản đều được đặt sau các phạm vi quyền riêng biệt. Kết quả là mỗi thông tin đăng nhập chỉ mang thẩm quyền mà nó được cấp một cách rõ ràng, thay vì kế thừa mọi khả năng gắn với tài khoản. Điều này làm thay đổi những gì xảy ra khi thông tin đăng nhập bị xâm phạm. Sự cố chỉ bị giới hạn trong phạm vi quyền của riêng khóa đó thay vì lan rộng trên toàn bộ tài khoản. Vì vậy, việc bổ sung các khả năng API mới không tự động làm tăng mức độ nghiêm trọng của một sự cố xâm phạm hiện có, vì thẩm quyền mới được giới thiệu vẫn được tách biệt khỏi các thông tin đăng nhập chưa bao giờ được cấp quyền đó. Đây chính là lúc Blast Radius Reduction bắt đầu lộ diện. Khi thẩm quyền được phép mở rộng thông qua các phạm vi quyền độc lập thay vì tích tụ sau cùng một thông tin đăng nhập, nền tảng có thể tiếp tục mở rộng mà không phải buộc rủi ro tăng lên theo cùng một cách. Các khả năng mới giúp GRVT làm được nhiều hơn, trong khi mỗi ranh giới quyền vẫn tiếp tục chứa đựng hậu quả của sự xâm phạm đối với ranh giới đó. Nhìn lại, các quyền API đó giờ đây không còn giống như một sự tiện lợi dành cho nhà phát triển nữa. Chúng cho thấy GRVT kỳ vọng nền tảng sẽ phát triển như thế nào. Khi nhiều API, sản phẩm và quy trình làm việc được giới thiệu hơn, thẩm quyền không nhất thiết phải hội tụ vào một thông tin đăng nhập duy nhất. Nếu nguyên tắc này tiếp tục được giữ vững, Blast Radius Reduction sẽ mở rộng cùng với GRVT, cho phép @grvt_io mở rộng mà không phải mọi khả năng mới trở thành một nguồn rủi ro dùng chung khác. $TAG $LAB #grvt

Vài ngày trước, tôi nhận thấy một chi tiết thú vị khi khám phá GRVT. Các khóa API khác nhau có thể được gán các quyền khác nhau. Một số được phép đặt lệnh. Một số khác có thể chuyển tài sản. Một số thì bị giới hạn ở quyền chỉ đọc. Không có khóa nào được kỳ vọng sẽ làm được mọi thứ.
Thay vì coi quyền truy cập như một tính năng tiện lợi, GRVT sử dụng chúng để phân tách thẩm quyền trước khi bất kỳ thao tác nào bắt đầu.
Mọi khả năng mới trên GRVT không tự động trở nên sẵn dùng cho mọi khóa API. Giao dịch, nạp tiền, rút tiền và quản lý tài khoản đều được đặt sau các phạm vi quyền riêng biệt. Kết quả là mỗi thông tin đăng nhập chỉ mang thẩm quyền mà nó được cấp một cách rõ ràng, thay vì kế thừa mọi khả năng gắn với tài khoản.
Điều này làm thay đổi những gì xảy ra khi thông tin đăng nhập bị xâm phạm.
Sự cố chỉ bị giới hạn trong phạm vi quyền của riêng khóa đó thay vì lan rộng trên toàn bộ tài khoản. Vì vậy, việc bổ sung các khả năng API mới không tự động làm tăng mức độ nghiêm trọng của một sự cố xâm phạm hiện có, vì thẩm quyền mới được giới thiệu vẫn được tách biệt khỏi các thông tin đăng nhập chưa bao giờ được cấp quyền đó.
Đây chính là lúc Blast Radius Reduction bắt đầu lộ diện.
Khi thẩm quyền được phép mở rộng thông qua các phạm vi quyền độc lập thay vì tích tụ sau cùng một thông tin đăng nhập, nền tảng có thể tiếp tục mở rộng mà không phải buộc rủi ro tăng lên theo cùng một cách. Các khả năng mới giúp GRVT làm được nhiều hơn, trong khi mỗi ranh giới quyền vẫn tiếp tục chứa đựng hậu quả của sự xâm phạm đối với ranh giới đó.
Nhìn lại, các quyền API đó giờ đây không còn giống như một sự tiện lợi dành cho nhà phát triển nữa. Chúng cho thấy GRVT kỳ vọng nền tảng sẽ phát triển như thế nào. Khi nhiều API, sản phẩm và quy trình làm việc được giới thiệu hơn, thẩm quyền không nhất thiết phải hội tụ vào một thông tin đăng nhập duy nhất. Nếu nguyên tắc này tiếp tục được giữ vững, Blast Radius Reduction sẽ mở rộng cùng với GRVT, cho phép @grvt_io mở rộng mà không phải mọi khả năng mới trở thành một nguồn rủi ro dùng chung khác.
$TAG $LAB #grvt

TAG+9,77%

Có phải Newton Protocol đang làm thay đổi cost để tham gia hệ sinh thái?Tối thứ bảy tuần trước, khoảng 6 giờ tối, mình cùng vài người bạn đi ăn hải sản ở một quán trên đường Võ Văn Kiệt. Bàn gọi khá nhiều món, trong đó có một phần hàu nướng mỡ hành. Trong lúc đợi món, mình hỏi anh chủ quán: "Ngày nào cũng phải chuẩn bị nhiều hàu như vậy, lỡ hôm nay bán ít thì sao?" Anh cười rồi chỉ về khu sơ chế. "Khó nhất là nhập hàng và sơ chế. Làm xong phần đó rồi thì bán thêm một đĩa nữa gần như không tốn bao nhiêu công." Câu trả lời đó làm mình nhớ đến Policy Packs trong docs của Newton Protocol. Khi sử dụng một Policy Pack, developer không cần tự viết hay deploy Data Oracle. Oracle đã được triển khai sẵn với PolicyData Address, WASM CID và toàn bộ metadata trong deployments.json. Việc còn lại chỉ là cấu hình params, upload secrets nếu cần rồi bắt đầu viết Policy. Thoạt nhìn, đây chỉ giống một cách giúp developer bắt đầu nhanh hơn. Nhưng càng đọc, mình càng thấy Newton Protocol đang thay đổi mức chi phí tối thiểu để một Policy có thể tồn tại. Thông thường, nếu một use case chỉ phục vụ một nhóm người dùng nhỏ, developer rất khó biện minh cho việc xây dựng và duy trì cả một Data Oracle riêng. Không phải vì Decision đó không có giá trị, mà vì chi phí của lớp Infrastructure lớn hơn chính giá trị mà use case đó tạo ra. Policy Packs đảo ngược bài toán này. Chi phí xây dựng và duy trì Data Oracle được đầu tư một lần rồi nhiều Policies cùng sử dụng. Infrastructure không còn phải được tạo lại mỗi khi xuất hiện một use case mới. Builder chỉ cần tập trung vào cách diễn giải Data để tạo ra Decision của riêng mình. Đó cũng là lúc một Cost Floor mới bắt đầu hình thành. Khi Cost Floor của việc tạo ra một Policy thấp hơn, nhiều use case trước đây không đủ lớn để mang ý nghĩa kinh tế bắt đầu trở nên khả thi. Một Policy không còn phải phục vụ một thị trường đủ lớn để "nuôi" cả một Data Oracle riêng. Chỉ cần cách diễn giải Data đó giải quyết đúng một nhu cầu cụ thể, builder đã có lý do để xây dựng nó. Chính từ đó, Market Coverage bắt đầu mở rộng. Ecosystem không chỉ có thêm nhiều Policies hơn. Nó còn bắt đầu bao phủ những nhu cầu rất nhỏ mà trước đây luôn bị bỏ qua vì chi phí của lớp Infrastructure quá cao. Những khoảng trống không đủ lớn để tồn tại như một dự án riêng giờ vẫn có thể được phục vụ trên cùng một Data Oracle. Nhìn theo góc đó, giá trị của Policy Packs không chỉ nằm ở việc chia sẻ Infrastructure. Newton Protocol đang hạ thấp Cost Floor để mở rộng Market Coverage của toàn bộ ecosystem. Khi chi phí tối thiểu để phục vụ một nhu cầu tiếp tục giảm, ngày càng nhiều thị trường nhỏ sẽ trở nên có ý nghĩa kinh tế. Nếu quá trình này tiếp tục diễn ra, lợi thế dài hạn của @NewtonProtocol sẽ không chỉ nằm ở số lượng Policy Packs, mà ở khả năng biến những nhu cầu trước đây quá nhỏ để tồn tại thành một phần của cùng một ecosystem. $LAB $NEWT #Newt

Đã xác minh

Bài viết

Có phải Newton Protocol đang làm thay đổi cost để tham gia hệ sinh thái?

Tối thứ bảy tuần trước, khoảng 6 giờ tối, mình cùng vài người bạn đi ăn hải sản ở một quán trên đường Võ Văn Kiệt. Bàn gọi khá nhiều món, trong đó có một phần hàu nướng mỡ hành.
Trong lúc đợi món, mình hỏi anh chủ quán:
"Ngày nào cũng phải chuẩn bị nhiều hàu như vậy, lỡ hôm nay bán ít thì sao?"
Anh cười rồi chỉ về khu sơ chế.
"Khó nhất là nhập hàng và sơ chế. Làm xong phần đó rồi thì bán thêm một đĩa nữa gần như không tốn bao nhiêu công."
Câu trả lời đó làm mình nhớ đến Policy Packs trong docs của Newton Protocol.
Khi sử dụng một Policy Pack, developer không cần tự viết hay deploy Data Oracle. Oracle đã được triển khai sẵn với PolicyData Address, WASM CID và toàn bộ metadata trong deployments.json. Việc còn lại chỉ là cấu hình params, upload secrets nếu cần rồi bắt đầu viết Policy.
Thoạt nhìn, đây chỉ giống một cách giúp developer bắt đầu nhanh hơn.
Nhưng càng đọc, mình càng thấy Newton Protocol đang thay đổi mức chi phí tối thiểu để một Policy có thể tồn tại.
Thông thường, nếu một use case chỉ phục vụ một nhóm người dùng nhỏ, developer rất khó biện minh cho việc xây dựng và duy trì cả một Data Oracle riêng. Không phải vì Decision đó không có giá trị, mà vì chi phí của lớp Infrastructure lớn hơn chính giá trị mà use case đó tạo ra.
Policy Packs đảo ngược bài toán này.
Chi phí xây dựng và duy trì Data Oracle được đầu tư một lần rồi nhiều Policies cùng sử dụng. Infrastructure không còn phải được tạo lại mỗi khi xuất hiện một use case mới. Builder chỉ cần tập trung vào cách diễn giải Data để tạo ra Decision của riêng mình.
Đó cũng là lúc một Cost Floor mới bắt đầu hình thành.
Khi Cost Floor của việc tạo ra một Policy thấp hơn, nhiều use case trước đây không đủ lớn để mang ý nghĩa kinh tế bắt đầu trở nên khả thi. Một Policy không còn phải phục vụ một thị trường đủ lớn để "nuôi" cả một Data Oracle riêng. Chỉ cần cách diễn giải Data đó giải quyết đúng một nhu cầu cụ thể, builder đã có lý do để xây dựng nó.
Chính từ đó, Market Coverage bắt đầu mở rộng.
Ecosystem không chỉ có thêm nhiều Policies hơn. Nó còn bắt đầu bao phủ những nhu cầu rất nhỏ mà trước đây luôn bị bỏ qua vì chi phí của lớp Infrastructure quá cao. Những khoảng trống không đủ lớn để tồn tại như một dự án riêng giờ vẫn có thể được phục vụ trên cùng một Data Oracle.
Nhìn theo góc đó, giá trị của Policy Packs không chỉ nằm ở việc chia sẻ Infrastructure. Newton Protocol đang hạ thấp Cost Floor để mở rộng Market Coverage của toàn bộ ecosystem. Khi chi phí tối thiểu để phục vụ một nhu cầu tiếp tục giảm, ngày càng nhiều thị trường nhỏ sẽ trở nên có ý nghĩa kinh tế. Nếu quá trình này tiếp tục diễn ra, lợi thế dài hạn của @NewtonProtocol sẽ không chỉ nằm ở số lượng Policy Packs, mà ở khả năng biến những nhu cầu trước đây quá nhỏ để tồn tại thành một phần của cùng một ecosystem.
$LAB $NEWT #Newt

Khi sử dụng một Policy Pack trong Newton Protocol, developer không cần tự build hay deploy Data Oracle. Data Oracle đã được triển khai sẵn. Việc còn lại chỉ là tham chiếu đến PolicyData Address, cấu hình các Parameters cần thiết rồi bắt đầu viết Policy. Với workflow này, mình nghĩ Newton Protocol đang thay đổi loại Cost mà developer phải trả. Nếu tự xây toàn bộ Data Oracle, mỗi lần update hay Maintenance đều lấy đi một phần thời gian vốn có thể dành cho việc cải thiện Decision. Mỗi giờ dành cho Maintenance đồng nghĩa với ít thời gian hơn để thử Ideas mới. Policy Packs đảo ngược điều đó. Khi Infrastructure đã được duy trì sẵn, Maintenance không còn là gánh nặng mà từng developer phải lặp lại. Thời gian được trả về để thiết kế Policy, điều chỉnh Business Logic và thử Decisions mới. Cost lớn nhất không còn nằm ở việc vận hành Infrastructure, mà chuyển sang việc tìm ra cách diễn giải Data tốt hơn. Đó cũng là lúc Opportunity Cost bắt đầu thay đổi. Mỗi giờ không phải dành cho Maintenance đồng nghĩa với thêm một giờ để thử một Policy, kiểm chứng Assumption hoặc tối ưu một Decision. Value của Policy Packs không chỉ nằm ở việc giảm khối lượng công việc, mà ở việc chuyển thời gian sang những hoạt động tạo ra nhiều khác biệt hơn. Nhìn theo góc đó, mình thấy Newton Protocol không chỉ cung cấp những Policy Packs có sẵn. Mà đang dịch chuyển Opportunity Cost của developer khỏi những công việc lặp lại để tập trung vào Innovation. Nếu ngày càng nhiều builders cùng bắt đầu từ một lớp Infrastructure chung, lợi thế của @NewtonProtocol sẽ dần tích lũy ở chất lượng của Decision, bởi ngày càng nhiều nguồn lực được chuyển từ Maintenance sang Innovation #Newt $SKL $LAB $NEWT

Khi sử dụng một Policy Pack trong Newton Protocol, developer không cần tự build hay deploy Data Oracle. Data Oracle đã được triển khai sẵn. Việc còn lại chỉ là tham chiếu đến PolicyData Address, cấu hình các Parameters cần thiết rồi bắt đầu viết Policy.
Với workflow này, mình nghĩ Newton Protocol đang thay đổi loại Cost mà developer phải trả.
Nếu tự xây toàn bộ Data Oracle, mỗi lần update hay Maintenance đều lấy đi một phần thời gian vốn có thể dành cho việc cải thiện Decision. Mỗi giờ dành cho Maintenance đồng nghĩa với ít thời gian hơn để thử Ideas mới.
Policy Packs đảo ngược điều đó.
Khi Infrastructure đã được duy trì sẵn, Maintenance không còn là gánh nặng mà từng developer phải lặp lại. Thời gian được trả về để thiết kế Policy, điều chỉnh Business Logic và thử Decisions mới. Cost lớn nhất không còn nằm ở việc vận hành Infrastructure, mà chuyển sang việc tìm ra cách diễn giải Data tốt hơn.
Đó cũng là lúc Opportunity Cost bắt đầu thay đổi.
Mỗi giờ không phải dành cho Maintenance đồng nghĩa với thêm một giờ để thử một Policy, kiểm chứng Assumption hoặc tối ưu một Decision. Value của Policy Packs không chỉ nằm ở việc giảm khối lượng công việc, mà ở việc chuyển thời gian sang những hoạt động tạo ra nhiều khác biệt hơn.
Nhìn theo góc đó, mình thấy Newton Protocol không chỉ cung cấp những Policy Packs có sẵn. Mà đang dịch chuyển Opportunity Cost của developer khỏi những công việc lặp lại để tập trung vào Innovation. Nếu ngày càng nhiều builders cùng bắt đầu từ một lớp Infrastructure chung, lợi thế của @NewtonProtocol sẽ dần tích lũy ở chất lượng của Decision, bởi ngày càng nhiều nguồn lực được chuyển từ Maintenance sang Innovation #Newt $SKL $LAB $NEWT

Bài viết

Điều gì khiến giá trị của Data Oracles trong Newton Protocol tiếp tục tăng theo thời gian?Tối chủ nhật tuần trước, khoảng 7 giờ, mình ghé một quán cơm trên đường Nguyễn Duy. Gọi một phần heo quay giòn bì, mình để ý đầu bếp không chuẩn bị mọi thứ cùng một lúc. Miếng thịt đã được quay từ trước. Phần nước sốt được múc từ một nồi khác. Dưa chua, rau và nước chấm cũng được lấy từ những khay riêng. Chỉ đến khi khách gọi món, tất cả mới được đặt lên cùng một chiếc đĩa. Mình hỏi vui: "Sao không làm sẵn từng phần hoàn chỉnh cho nhanh?" Anh đầu bếp cười. "Nếu làm vậy thì mỗi lần đổi một món là phải sửa tất cả. Còn tách riêng từng phần thế này thì thịt vẫn là thịt, nước chấm vẫn là nước chấm. Muốn bán món mới thì chỉ cần ghép chúng theo cách khác." Câu trả lời đó làm mình nhớ đến phần nói về Chaining Multiple Data Oracles trong docs của Newton Protocol. Khi một Policy sử dụng nhiều Data Oracles, Newton Protocol không để các Oracle gọi lẫn nhau. Mỗi Data Oracle vẫn chạy độc lập, tạo ra phần dữ liệu của riêng mình rồi mạng lưới mới tổng hợp toàn bộ kết quả để Rego Policy đưa ra Decision cuối cùng. Thoạt nhìn, đây chỉ giống một lựa chọn về kiến trúc. Nhưng càng đọc, mình càng thấy Newton Protocol không cố làm cho từng Data Oracle biết nhiều hơn về hệ thống. Họ lại cố giữ cho mỗi Oracle chỉ tập trung vào đúng phần dữ liệu mà mình chịu trách nhiệm. Điều đó cũng đồng nghĩa khi một Data Oracle mới xuất hiện, những Oracle đã tồn tại không cần thay đổi. Chúng không cần biết Oracle mới là ai, cũng không cần học cách giao tiếp với thành phần mới. Toàn bộ việc kết hợp dữ liệu được chuyển lên Rego Policy, nơi các Decision mới được hình thành. Chính điều này làm mình nhìn giá trị của một Data Oracle theo cách khác. Nếu Oracle không bị gắn chặt với một Policy cụ thể, giá trị của nó không kết thúc ở lần tích hợp đầu tiên. Chỉ cần dữ liệu mà Oracle tạo ra vẫn hữu ích, nó có thể tiếp tục được sử dụng trong rất nhiều Policy khác nhau mà không cần thay đổi chính Oracle đó. Điều thú vị hơn xảy ra khi số lượng Data Oracles tiếp tục tăng. Mỗi Oracle mới không chỉ bổ sung thêm một nguồn dữ liệu. Nó còn tạo thêm những khả năng kết hợp mới với toàn bộ Oracle đã tồn tại trước đó. Một Oracle về Asset Price hôm nay có thể kết hợp với Oracle về KYC trong Policy này, với Oracle về Risk Score trong Policy khác, rồi tiếp tục tạo ra những Decision hoàn toàn mới khi hệ sinh thái xuất hiện thêm các Oracle khác. Giá trị của Oracle cũ vì thế không đứng yên. Nó tiếp tục tăng lên nhờ những cách kết hợp mà trước đây chưa từng tồn tại. Đến lúc đó, Newton Protocol không còn chỉ sở hữu nhiều Data Oracles hơn. @NewtonProtocol bắt đầu vận hành như một Recombination Economy. Trong một Recombination Economy, giá trị của từng module không chỉ đến từ chức năng mà nó tự tạo ra. Giá trị đó còn đến từ số lượng cách module có thể được tái kết hợp với những module khác. Mỗi Data Oracle mới không chỉ bổ sung thêm một tài nguyên mới cho mạng lưới, mà còn mở rộng giá trị của toàn bộ Oracle đã có trước đó. Có lẽ đây mới là điều mình thấy đáng chú ý ở Newton Protocol. Nhiều người nhìn khả năng Chaining Multiple Data Oracles như một cách để đưa nhiều nguồn dữ liệu vào cùng một Policy. Mình lại thấy giá trị lớn hơn nằm ở kiến trúc phía sau. Khi dependency được giữ bên ngoài Oracle và việc kết hợp chỉ diễn ra ở Rego Policy, mỗi Oracle đều có cơ hội tiếp tục tạo ra giá trị trong những ngữ cảnh hoàn toàn mới. Nếu hệ sinh thái đủ lớn, Recombination Economy có lẽ mới là lợi thế đáng theo dõi nhất của Newton Protocol, bởi giá trị của mạng lưới khi đó sẽ không chỉ tăng theo số lượng Data Oracles, mà còn theo số lượng cách chúng có thể được kết hợp với nhau. $EVAA $NEWT $BLUAI #Newt

Điều gì khiến giá trị của Data Oracles trong Newton Protocol tiếp tục tăng theo thời gian?

Tối chủ nhật tuần trước, khoảng 7 giờ, mình ghé một quán cơm trên đường Nguyễn Duy. Gọi một phần heo quay giòn bì, mình để ý đầu bếp không chuẩn bị mọi thứ cùng một lúc.
Miếng thịt đã được quay từ trước. Phần nước sốt được múc từ một nồi khác. Dưa chua, rau và nước chấm cũng được lấy từ những khay riêng. Chỉ đến khi khách gọi món, tất cả mới được đặt lên cùng một chiếc đĩa.
Mình hỏi vui:
"Sao không làm sẵn từng phần hoàn chỉnh cho nhanh?"
Anh đầu bếp cười.
"Nếu làm vậy thì mỗi lần đổi một món là phải sửa tất cả. Còn tách riêng từng phần thế này thì thịt vẫn là thịt, nước chấm vẫn là nước chấm. Muốn bán món mới thì chỉ cần ghép chúng theo cách khác."
Câu trả lời đó làm mình nhớ đến phần nói về Chaining Multiple Data Oracles trong docs của Newton Protocol.
Khi một Policy sử dụng nhiều Data Oracles, Newton Protocol không để các Oracle gọi lẫn nhau. Mỗi Data Oracle vẫn chạy độc lập, tạo ra phần dữ liệu của riêng mình rồi mạng lưới mới tổng hợp toàn bộ kết quả để Rego Policy đưa ra Decision cuối cùng.
Thoạt nhìn, đây chỉ giống một lựa chọn về kiến trúc.
Nhưng càng đọc, mình càng thấy Newton Protocol không cố làm cho từng Data Oracle biết nhiều hơn về hệ thống. Họ lại cố giữ cho mỗi Oracle chỉ tập trung vào đúng phần dữ liệu mà mình chịu trách nhiệm.
Điều đó cũng đồng nghĩa khi một Data Oracle mới xuất hiện, những Oracle đã tồn tại không cần thay đổi. Chúng không cần biết Oracle mới là ai, cũng không cần học cách giao tiếp với thành phần mới. Toàn bộ việc kết hợp dữ liệu được chuyển lên Rego Policy, nơi các Decision mới được hình thành.
Chính điều này làm mình nhìn giá trị của một Data Oracle theo cách khác.
Nếu Oracle không bị gắn chặt với một Policy cụ thể, giá trị của nó không kết thúc ở lần tích hợp đầu tiên. Chỉ cần dữ liệu mà Oracle tạo ra vẫn hữu ích, nó có thể tiếp tục được sử dụng trong rất nhiều Policy khác nhau mà không cần thay đổi chính Oracle đó.
Điều thú vị hơn xảy ra khi số lượng Data Oracles tiếp tục tăng.
Mỗi Oracle mới không chỉ bổ sung thêm một nguồn dữ liệu. Nó còn tạo thêm những khả năng kết hợp mới với toàn bộ Oracle đã tồn tại trước đó. Một Oracle về Asset Price hôm nay có thể kết hợp với Oracle về KYC trong Policy này, với Oracle về Risk Score trong Policy khác, rồi tiếp tục tạo ra những Decision hoàn toàn mới khi hệ sinh thái xuất hiện thêm các Oracle khác. Giá trị của Oracle cũ vì thế không đứng yên. Nó tiếp tục tăng lên nhờ những cách kết hợp mà trước đây chưa từng tồn tại.
Đến lúc đó, Newton Protocol không còn chỉ sở hữu nhiều Data Oracles hơn.
@NewtonProtocol bắt đầu vận hành như một Recombination Economy.
Trong một Recombination Economy, giá trị của từng module không chỉ đến từ chức năng mà nó tự tạo ra. Giá trị đó còn đến từ số lượng cách module có thể được tái kết hợp với những module khác. Mỗi Data Oracle mới không chỉ bổ sung thêm một tài nguyên mới cho mạng lưới, mà còn mở rộng giá trị của toàn bộ Oracle đã có trước đó.
Có lẽ đây mới là điều mình thấy đáng chú ý ở Newton Protocol.
Nhiều người nhìn khả năng Chaining Multiple Data Oracles như một cách để đưa nhiều nguồn dữ liệu vào cùng một Policy. Mình lại thấy giá trị lớn hơn nằm ở kiến trúc phía sau. Khi dependency được giữ bên ngoài Oracle và việc kết hợp chỉ diễn ra ở Rego Policy, mỗi Oracle đều có cơ hội tiếp tục tạo ra giá trị trong những ngữ cảnh hoàn toàn mới. Nếu hệ sinh thái đủ lớn, Recombination Economy có lẽ mới là lợi thế đáng theo dõi nhất của Newton Protocol, bởi giá trị của mạng lưới khi đó sẽ không chỉ tăng theo số lượng Data Oracles, mà còn theo số lượng cách chúng có thể được kết hợp với nhau.
$EVAA $NEWT $BLUAI #Newt

Đã xác minh

Tìm hiểu về Chaining Multiple Data Oracles trong docs của Newton Protocol, mình khá bất ngờ với những gì Data Oracle không bao giờ làm. Mỗi Data Oracle chỉ trả về những Facts như risk_score, is_collapsed hay tvl_drawdown. Chúng không kết luận một transaction nên Allow hay Deny. Phần đó được để lại cho Rego Policy. Đây không chỉ là cách phân chia trách nhiệm. Mà còn cho thấy Newton Protocol đang tách Fact khỏi Judgment. Khi một Fact không còn gắn với một Judgment cố định, cùng một risk_score có thể được nhiều Policies diễn giải theo những tiêu chuẩn hoàn toàn khác nhau. Một policy coi 60 là đủ an toàn để Allow, policy khác lại chỉ chấp nhận từ 80 trở lên. Fact vẫn giữ nguyên, chỉ có Judgment thay đổi. Một Fact vì thế không còn kết thúc vai trò sau lần đầu được sử dụng. Khi xuất hiện thêm một Policy, chính Fact đó lại được diễn giải theo một tiêu chuẩn mới để tạo ra một Decision khác mà không cần thu thập lại dữ liệu từ đầu. Giá trị của một Fact cũng không còn dừng ở lần sử dụng đầu tiên. Mỗi Policy mới lại mở thêm một ngữ cảnh để Fact cũ tiếp tục tạo ra giá trị. Chính sự tách biệt giữa Fact và Judgment này đã tạo ra một Fact Appreciation Mechanism Điều mình thấy thú vị nhất là Newton Protocol không cố làm cho Data Oracles tạo ra nhiều Facts hơn. @NewtonProtocol làm cho mỗi Fact tiếp tục tạo ra giá trị sau khi đã được sinh ra. Khi hệ sinh thái có thêm Policies, những Facts cũ liên tục được diễn giải theo những tiêu chuẩn mới. Nếu quá trình đó tiếp tục lặp lại, Fact Appreciation Mechanism sẽ khiến giá trị của dữ liệu tăng lên cùng với sự phát triển của toàn bộ hệ sinh thái, thay vì chỉ dừng lại ở lần sử dụng đầu tiên. #Newt $EVAA $NEWT

Tìm hiểu về Chaining Multiple Data Oracles trong docs của Newton Protocol, mình khá bất ngờ với những gì Data Oracle không bao giờ làm.
Mỗi Data Oracle chỉ trả về những Facts như risk_score, is_collapsed hay tvl_drawdown. Chúng không kết luận một transaction nên Allow hay Deny. Phần đó được để lại cho Rego Policy.
Đây không chỉ là cách phân chia trách nhiệm.
Mà còn cho thấy Newton Protocol đang tách Fact khỏi Judgment.
Khi một Fact không còn gắn với một Judgment cố định, cùng một risk_score có thể được nhiều Policies diễn giải theo những tiêu chuẩn hoàn toàn khác nhau. Một policy coi 60 là đủ an toàn để Allow, policy khác lại chỉ chấp nhận từ 80 trở lên. Fact vẫn giữ nguyên, chỉ có Judgment thay đổi.
Một Fact vì thế không còn kết thúc vai trò sau lần đầu được sử dụng. Khi xuất hiện thêm một Policy, chính Fact đó lại được diễn giải theo một tiêu chuẩn mới để tạo ra một Decision khác mà không cần thu thập lại dữ liệu từ đầu.
Giá trị của một Fact cũng không còn dừng ở lần sử dụng đầu tiên.
Mỗi Policy mới lại mở thêm một ngữ cảnh để Fact cũ tiếp tục tạo ra giá trị. Chính sự tách biệt giữa Fact và Judgment này đã tạo ra một Fact Appreciation Mechanism
Điều mình thấy thú vị nhất là Newton Protocol không cố làm cho Data Oracles tạo ra nhiều Facts hơn. @NewtonProtocol làm cho mỗi Fact tiếp tục tạo ra giá trị sau khi đã được sinh ra. Khi hệ sinh thái có thêm Policies, những Facts cũ liên tục được diễn giải theo những tiêu chuẩn mới. Nếu quá trình đó tiếp tục lặp lại, Fact Appreciation Mechanism sẽ khiến giá trị của dữ liệu tăng lên cùng với sự phát triển của toàn bộ hệ sinh thái, thay vì chỉ dừng lại ở lần sử dụng đầu tiên.
#Newt $EVAA $NEWT

Newton Protocol đang tạo ra những trải nghiệm gì cho developer?Tối hôm qua, mình ngồi ăn với Oanh-một phú bà đang mở một nhà hàng hải sản. Oanh ấy kể rằng tuần nào cũng đổi một vài món trong menu. Mình khá ngạc nhiên. "Tần suất thay đổi thế này không sợ khách khó theo à?" Oanh lắc đầu. "Mình không đổi cả menu. Mình chỉ thử một món mới mỗi lần. Nếu khách không thích thì bỏ luôn. Chi phí của một lần thử đủ nhỏ nên mình chẳng có lý do gì để ngại thử tiếp." Câu nói đó làm mình nhớ đến phần Testing Policies & Oracles trong docs của Newton Protocol. Ban đầu, mình chỉ nghĩ đây là một quy trình testing được viết chi tiết hơn bình thường. Thay vì nói chung chung "test trước khi deploy", @NewtonProtocol tách thành nhiều bước rất rõ: Unit Test cho Rego Policy, test riêng từng WASM Oracle, rồi mới Simulation toàn bộ policy trước khi đưa lên mạng lưới. Nhưng càng đọc, mình càng thấy họ không chỉ đang sắp xếp lại quy trình testing. Mỗi lớp testing đều đưa feedback đến sớm hơn một chút. Sai ở Rego Policy được phát hiện khi policy còn đứng riêng. Sai ở WASM Oracle được phát hiện trước khi Oracle kết hợp với những thành phần khác. Chỉ khi từng mảnh đều hoạt động đúng, toàn bộ Decision mới được kiểm tra trong bước Simulation. Điều này khiến chi phí của mỗi lần thử thay đổi hoàn toàn. Nếu một Decision sai, developer không cần chờ đến lúc Deployment mới biết. Phần lớn sai sót đã được giữ lại ở lớp testing có chi phí thấp hơn nhiều. Một thay đổi nhỏ không còn kéo theo cả một vòng Deployment chỉ để nhận về kết luận rằng ý tưởng ban đầu chưa đúng. Khi chi phí của mỗi lần thử giảm xuống, hành vi của developer cũng bắt đầu thay đổi. Nếu mỗi ý tưởng mới đều đòi hỏi một vòng Deployment dài, mọi người sẽ có xu hướng chỉ chọn những phương án mà họ tin tưởng nhất. Nhưng khi feedback xuất hiện gần như ngay sau mỗi thay đổi, việc thử thêm một cách viết Rego Policy hay một Decision khác trở nên ít rủi ro hơn rất nhiều. Không phải vì xác suất thành công cao hơn, mà vì chi phí của thất bại đã thấp đi. Lúc đó mình mới nhận ra thứ Newton Protocol đang tạo ra không chỉ là một quy trình testing tốt hơn. Họ đang tạo ra nhiều Experimental Optionality hơn cho developer. Mỗi vòng feedback ngắn không chỉ giúp sửa bug nhanh hơn. Nó còn giữ lại nhiều lựa chọn hơn trong suốt quá trình phát triển. Một ý tưởng có thể bị loại bỏ rất sớm với chi phí rất nhỏ, trong khi một ý tưởng khác có thể được thử ngay sau đó mà gần như không làm chậm cả dự án. Có lẽ đây mới là điều mình thấy thú vị ở Newton Protocol. Phần lớn chúng ta thường đánh giá một quy trình testing bằng khả năng phát hiện lỗi. Mình lại thấy giá trị lớn hơn nằm ở số lượng lựa chọn mà quy trình đó giúp developer giữ lại. Khi mỗi lần thử đều trở nên rẻ hơn, hệ thống không chỉ phát triển nhanh hơn mà còn có nhiều cơ hội khám phá những Decision tốt hơn. Nếu nhìn theo góc đó, Experimental Optionality có lẽ mới là thứ Newton Protocol đang âm thầm tối ưu, chứ không đơn thuần là số lượng bài test hay tốc độ Deployment. $EVAA $NEWT #Newt

Đã xác minh

Bài viết

Newton Protocol đang tạo ra những trải nghiệm gì cho developer?

Tối hôm qua, mình ngồi ăn với Oanh-một phú bà đang mở một nhà hàng hải sản. Oanh ấy kể rằng tuần nào cũng đổi một vài món trong menu.
Mình khá ngạc nhiên.
"Tần suất thay đổi thế này không sợ khách khó theo à?"
Oanh lắc đầu.
"Mình không đổi cả menu. Mình chỉ thử một món mới mỗi lần. Nếu khách không thích thì bỏ luôn. Chi phí của một lần thử đủ nhỏ nên mình chẳng có lý do gì để ngại thử tiếp."
Câu nói đó làm mình nhớ đến phần Testing Policies & Oracles trong docs của Newton Protocol.
Ban đầu, mình chỉ nghĩ đây là một quy trình testing được viết chi tiết hơn bình thường. Thay vì nói chung chung "test trước khi deploy", @NewtonProtocol tách thành nhiều bước rất rõ: Unit Test cho Rego Policy, test riêng từng WASM Oracle, rồi mới Simulation toàn bộ policy trước khi đưa lên mạng lưới.
Nhưng càng đọc, mình càng thấy họ không chỉ đang sắp xếp lại quy trình testing.
Mỗi lớp testing đều đưa feedback đến sớm hơn một chút. Sai ở Rego Policy được phát hiện khi policy còn đứng riêng. Sai ở WASM Oracle được phát hiện trước khi Oracle kết hợp với những thành phần khác. Chỉ khi từng mảnh đều hoạt động đúng, toàn bộ Decision mới được kiểm tra trong bước Simulation.
Điều này khiến chi phí của mỗi lần thử thay đổi hoàn toàn.
Nếu một Decision sai, developer không cần chờ đến lúc Deployment mới biết. Phần lớn sai sót đã được giữ lại ở lớp testing có chi phí thấp hơn nhiều. Một thay đổi nhỏ không còn kéo theo cả một vòng Deployment chỉ để nhận về kết luận rằng ý tưởng ban đầu chưa đúng.
Khi chi phí của mỗi lần thử giảm xuống, hành vi của developer cũng bắt đầu thay đổi.
Nếu mỗi ý tưởng mới đều đòi hỏi một vòng Deployment dài, mọi người sẽ có xu hướng chỉ chọn những phương án mà họ tin tưởng nhất. Nhưng khi feedback xuất hiện gần như ngay sau mỗi thay đổi, việc thử thêm một cách viết Rego Policy hay một Decision khác trở nên ít rủi ro hơn rất nhiều. Không phải vì xác suất thành công cao hơn, mà vì chi phí của thất bại đã thấp đi.
Lúc đó mình mới nhận ra thứ Newton Protocol đang tạo ra không chỉ là một quy trình testing tốt hơn.
Họ đang tạo ra nhiều Experimental Optionality hơn cho developer.
Mỗi vòng feedback ngắn không chỉ giúp sửa bug nhanh hơn. Nó còn giữ lại nhiều lựa chọn hơn trong suốt quá trình phát triển. Một ý tưởng có thể bị loại bỏ rất sớm với chi phí rất nhỏ, trong khi một ý tưởng khác có thể được thử ngay sau đó mà gần như không làm chậm cả dự án.
Có lẽ đây mới là điều mình thấy thú vị ở Newton Protocol.
Phần lớn chúng ta thường đánh giá một quy trình testing bằng khả năng phát hiện lỗi. Mình lại thấy giá trị lớn hơn nằm ở số lượng lựa chọn mà quy trình đó giúp developer giữ lại. Khi mỗi lần thử đều trở nên rẻ hơn, hệ thống không chỉ phát triển nhanh hơn mà còn có nhiều cơ hội khám phá những Decision tốt hơn. Nếu nhìn theo góc đó, Experimental Optionality có lẽ mới là thứ Newton Protocol đang âm thầm tối ưu, chứ không đơn thuần là số lượng bài test hay tốc độ Deployment.
$EVAA $NEWT #Newt

Trước khi deploy một policy, Newton Protocol yêu cầu đi qua ba bước: Unit Test cho Rego Policy, test riêng từng WASM Oracle, rồi mới simulate toàn bộ policy với real-world data. Ba bước này không đơn thuần kiểm tra từng thành phần riêng lẻ. Mà được sắp xếp để liên tục thu hẹp những điều còn chưa biết về một decision. Sau round validation, scope của những gì phải chờ đến deployment mới xác nhận lại ngày càng nhỏ đi. Thông thường, deployment là thời điểm quan trọng nhất để biết một decision có hoạt động như kỳ vọng hay không. Dù đã trải qua nhiều round testing, môi trường production vẫn là nơi nhiều đội ngũ chấp nhận học những điều họ chưa thể biết trước. Còn với Newton Protocol, phần lớn process đó diễn ra ngay trong development. Rego Policy, WASM Oracle và data được ghép lại để simulate toàn bộ decision trước khi deployment diễn ra. Điều đó khiến mình nghĩ Newton Protocol đang hướng tới kiến trúc Pre-validated Deployment. Lúc này, deployment chủ yếu trở thành bước release một decision đã được validated, thay vì là nơi hệ thống tiếp tục học xem decision đó đúng hay sai. Điều mình thấy đáng chú ý là Newton Protocol dường như đang thay đổi vai trò của Deployment. Khi Deployment không còn là nơi tạo ra Validation, nó cũng không còn là nơi hệ thống học xem một Decision đúng hay sai. Có lẽ đó mới là ý nghĩa của kiến trúc Pre-validated Deployment. Không phải một quy trình Testing đầy đủ hơn, mà là một architectural principle dịch chuyển hoạt động Validation khỏi Production. Mình khá tò mò liệu đây sẽ chỉ là một lựa chọn của Newton Protocol, hay sẽ dần trở thành cách nhiều hệ thống software được xây dựng trong tương lai? $EVAA $NEWT #Newt @NewtonProtocol

Đã xác minh

Trước khi deploy một policy, Newton Protocol yêu cầu đi qua ba bước: Unit Test cho Rego Policy, test riêng từng WASM Oracle, rồi mới simulate toàn bộ policy với real-world data.
Ba bước này không đơn thuần kiểm tra từng thành phần riêng lẻ. Mà được sắp xếp để liên tục thu hẹp những điều còn chưa biết về một decision. Sau round validation, scope của những gì phải chờ đến deployment mới xác nhận lại ngày càng nhỏ đi.
Thông thường, deployment là thời điểm quan trọng nhất để biết một decision có hoạt động như kỳ vọng hay không. Dù đã trải qua nhiều round testing, môi trường production vẫn là nơi nhiều đội ngũ chấp nhận học những điều họ chưa thể biết trước.
Còn với Newton Protocol, phần lớn process đó diễn ra ngay trong development. Rego Policy, WASM Oracle và data được ghép lại để simulate toàn bộ decision trước khi deployment diễn ra. Điều đó khiến mình nghĩ Newton Protocol đang hướng tới kiến trúc Pre-validated Deployment.
Lúc này, deployment chủ yếu trở thành bước release một decision đã được validated, thay vì là nơi hệ thống tiếp tục học xem decision đó đúng hay sai.
Điều mình thấy đáng chú ý là Newton Protocol dường như đang thay đổi vai trò của Deployment. Khi Deployment không còn là nơi tạo ra Validation, nó cũng không còn là nơi hệ thống học xem một Decision đúng hay sai.
Có lẽ đó mới là ý nghĩa của kiến trúc Pre-validated Deployment. Không phải một quy trình Testing đầy đủ hơn, mà là một architectural principle dịch chuyển hoạt động Validation khỏi Production. Mình khá tò mò liệu đây sẽ chỉ là một lựa chọn của Newton Protocol, hay sẽ dần trở thành cách nhiều hệ thống software được xây dựng trong tương lai? $EVAA $NEWT #Newt @NewtonProtocol