Tôi đã đọc đủ nhiều các bản pitch kiểu “chúng tôi không phải là X, chúng tôi cũng không phải là Y” trong lĩnh vực này để cảm thấy hơi mệt mỏi với chúng… thường thì điều đó có nghĩa là đội ngũ vẫn chưa xác định được chính xác họ thực sự là gì. Nhưng khi tôi dành một thời gian để xem xét cách Newton Protocol định vị mình, có điều gì đó về nó lại cứ kéo tôi quay trở lại, thay vì cho phép tôi gạt bỏ nó sang một bên.
Newton không tự gọi mình là một blockchain. Nó cũng không gọi mình là một ví, và còn cố tình nói rõ rằng mình không phải là một nhà cung cấp tuân thủ tập trung. Đó là một vị trí khá lạ để cắm cờ, bởi vì đa số dự án muốn trở thành một thứ gì đó rõ ràng—một thứ bạn có thể xếp vào một hạng mục và chuyển sang phần khác. Vì vậy, tôi bắt đầu tự hỏi: sau khi loại bỏ cả ba nhãn đó, thì rốt cuộc thứ gì còn lại? Câu hỏi ấy đã kéo tôi đi sâu hơn vào việc tìm hiểu kỹ về $NEWT.
Thứ thu hút sự chú ý của tôi ngay lập tức là Gateway. Nó được mô tả như một bộ điều phối luân phiên (rotating orchestrator), tức là vai trò phối hợp yêu cầu không đứng cố định ở một thực thể duy nhất; nó di chuyển giữa các nhà vận hành theo cơ chế chọn dựa trên VRF mỗi epoch, tương tự về tinh thần cách Ethereum luân phiên các proposer khối. Phản ứng thật lòng của tôi là: “Ừ thì luân phiên trên giấy không phải là luân phiên trong thực tế”, và sự hoài nghi đó khiến tôi thấy là hợp lý. Tuy vậy, điều làm cho tôi bớt cứng lại một chút là Gateway đã bị “đóng khung” về mặt cấu trúc ngay cả trước khi cơ chế luân phiên được triển khai: nó không thể giả mạo chữ ký của nhà vận hành hay âm thầm thay đổi kết quả mà không bị chính các nhà vận hành phát hiện qua các attestations của họ. Đó là một khác biệt đáng kể so với việc chỉ tin vào lời của một công ty.
Một điều khác đáng để dừng lại suy nghĩ là cách các nhà vận hành thực sự nhận được thẩm quyền. Họ không được bổ nhiệm; họ được đăng ký thông qua khung AVS của EigenLayer, và dùng ETH đã restake hoặc các token staking thanh khoản làm tài sản thế chấp. Tôi đã dừng lại tại đây và nghĩ về một ví dụ nhỏ: như một nhà thầu phải đặt cọc/bảo đảm trước khi được phép đụng tay vào việc cải tạo của bạn... nếu họ làm hỏng gì đó, thì đã có tiền nằm trên bàn, vượt ra ngoài lời hứa của họ. Việc số stake đó có đủ lớn để thực sự “đáng kể” hay không là câu hỏi khác, và tôi nghĩ chưa ai có thể trả lời ngay được.
Bản thân lớp chính sách chạy trên Rego, nội dung được địa chỉ hóa theo IPFS, nên mọi nhà vận hành đều đọc đúng cùng một bộ quy tắc theo CID. Điều này giải quyết một vấn đề thực sự mà tôi từng thấy ở các dự án “tuân thủ” khác: mỗi ứng dụng lặng lẽ tự chạy logic của riêng mình và không ai có thể so sánh kết quả. Ở đây ít nhất thì quy tắc là giống nhau cho mọi người, dù tôi chưa hoàn toàn thuyết phục rằng việc thực thi khớp với sự tinh xảo của thiết kế.
Cũng có cơ chế “force inclusion” (ép đưa vào), cho phép các ứng dụng bỏ qua Gateway hoàn toàn nếu nghi ngờ bị kiểm duyệt. Tôi thích vì nó tồn tại như một “cửa thoát hiểm”, nhưng cửa thoát hiểm chỉ thực sự có ý nghĩa khi ai đó đã từng cần dùng nó—và hiện tại, điều này vẫn chưa được kiểm chứng trong thế giới thực.
Phần có thể thú vị nhất với tôi là sự so sánh mà Newton đưa ra với các nhóm danh mục hiện có: API tập trung, token danh tính soulbound, logic chính sách theo từng ứng dụng. Mỗi thứ đều có một hạn chế thật sự mà Newton đang cố gắng giải quyết, nhưng giải quyết đồng thời năm vấn đề thường đồng nghĩa với việc kéo theo những vấn đề mới mà chưa ai kịp lập bản đồ.
Quay lại câu hỏi ban đầu: một giao thức như thế này thực sự thuộc về đâu? Câu trả lời thật lòng của tôi là nó đang tự tạo một “làn đường” giữa hạ tầng và việc thực thi, không nắm trọn hoàn toàn một bên nào—và đó là một vị trí khá khó chịu để xây dựng từ... nhưng có lẽ đây là nơi duy nhất mà lớp chính sách kiểu này có thể hoạt động 🤔
Tôi không đưa ra phán quyết ở đây; tôi chỉ nhận thấy $NEWT đang đặt ra những câu hỏi khó hơn hầu hết các dự án khác, những dự án thường không tự hỏi những điều đó.
DYOR rõ ràng... $NEWT
