Khi mọi người đánh giá các dự án hạ tầng, họ thường bắt đầu với slide sai.
Các nhà đầu tư.
Vòng gọi vốn.
Các logo.
Những chi tiết đó có thể cho bạn biết ai là người tin tưởng dự án từ sớm.
Chúng cho bạn biết rất ít về việc công nghệ thực sự có thể đến được với các nhà phát triển hay không.
Đó là lý do tôi nghĩ câu chuyện phía sau @NewtonProtocol bắt đầu ở nơi khác.
Magic Labs.
Phần lớn mọi người biết Magic Labs nhờ hạ tầng ví nhúng.
Hàng triệu ví.
Một hệ sinh thái nhà phát triển lớn.
Những năm tháng giảm bớt ma sát giữa người dùng và các ứng dụng blockchain.
Nền tảng đó đối với tôi còn thú vị hơn là danh sách các quỹ đầu tư mạo hiểm.
Bởi vì việc áp dụng hạ tầng hiếm khi chỉ được quyết định bởi kiến trúc.
Nó được quyết định bởi phân phối (distribution).
◆ Crypto có thói quen coi ưu thế kỹ thuật như thể nó tự động tạo ra hiệu ứng mạng.
Lịch sử gợi ý điều ngược lại.
Đã có vô số giao thức với những bản whitepaper tuyệt vời nhưng thất bại vì các nhà phát triển có ít lý do để tích hợp thêm một phụ thuộc nữa vào những hệ thống vốn đã phức tạp.
Các nhà phát triển thường hỏi những câu hỏi mang tính thực tế.
Việc tích hợp khó đến mức nào?
Các API ổn định đến mức nào?
Điều này có giảm công việc vận hành không?
Các ứng dụng hiện có có thể áp dụng mà không cần xây lại mọi thứ không?
Những câu hỏi đó quan trọng từ rất sớm, trước khi các vấn đề về token economics bước vào cuộc trò chuyện.
Đó là một lý do khiến Magic Labs nổi bật.
Kinh nghiệm của nó phần lớn nằm ở phía trải nghiệm dành cho nhà phát triển trong Web3.
Hạ tầng ví không phải thứ hào nhoáng.
Người dùng hiếm khi ăn mừng các lần xác thực thành công hay trải nghiệm onboarding mượt mà.
Nhưng các nhà phát triển sẽ nhận thấy khi những phần đó hoạt động ổn định.
Trải nghiệm đó trở nên liên quan khi Newton giới thiệu một điều gì đó hoàn toàn khác:
một lớp ủy quyền mà ứng dụng gọi trước khi giao dịch được hoàn tất.
🔍 Hãy nghĩ xem điều đó có ý nghĩa gì từ góc nhìn của một người xây dựng (builder).
Một giao thức đã có smart contracts.
Một giao diện frontend.
Khả năng kết nối ví.
Hạ tầng lập chỉ mục (indexing).
Hệ thống giám sát.
Có lẽ là một oracle.
Có lẽ là một nhà cung cấp tuân thủ (compliance).
Giờ đây lại xuất hiện một lớp khác nằm giữa ý định giao dịch và khâu thực thi.
Lớp đó cần phải biện minh cho sự tồn tại của nó.
Không phải thông qua marketing.
Thông qua giá trị tích hợp.
Nếu các nhà phát triển tin rằng việc thêm Newton sẽ cải thiện đáng kể các cơ chế kiểm soát rủi ro có thể thực thi, đồng thời vẫn đủ dễ để tích hợp, thì việc áp dụng sẽ trở nên thực tế hơn.
Nếu tích hợp tạo ra quá nhiều ma sát, ngay cả những ý tưởng bảo mật mạnh cũng có thể chỉ dừng ở “mảng ngách”.
Vì vậy công cụ dành cho nhà phát triển xứng đáng được chú ý nhiều hơn so với mức thường nhận được.
Hạ tầng thành công khi nó “biến mất” vào trong luồng công việc.
Không phải khi mọi lần tích hợp biến thành một dự án kỹ thuật kéo dài sáu tháng.
👀 Có một lợi thế khác mà kinh nghiệm có thể mang lại.
Magic Labs đã dành nhiều năm quan sát cách các ứng dụng thực sự vận hành sau khi ra mắt.
Không chỉ là cách chúng trông như thế nào trong tài liệu kỹ thuật.
Các nhà cung cấp ví nhìn thấy các lỗi thất bại khi onboarding.
Các trường hợp biên về xác thực (authentication).
Hành vi người dùng bất ngờ.
Độ phức tạp đa chuỗi (cross-chain).
Phiếu/báo cáo hỗ trợ (support tickets).
Nhóm sản phẩm.
Yêu cầu của doanh nghiệp.
Góc nhìn vận hành đó khác với việc thiết kế toàn bộ một giao thức chỉ trong môi trường nghiên cứu.
Newton sẽ được lợi nếu những bài học đó chuyển hóa thành API tốt hơn, SDK tốt hơn, tài liệu rõ ràng hơn và chi phí tích hợp thấp hơn.
Nhưng đây cũng là nơi tôi nghĩ mọi người cần phải cẩn trọng.
Nền tảng phát triển vững mạnh không đồng nghĩa với việc giao thức chắc chắn được áp dụng.
Ví nhúng giải quyết một nhóm vấn đề.
Hạ tầng ủy quyền giải quyết một bài toán khác.
Khách hàng là một nhóm khác.
Quyết định mua lại là một câu chuyện khác.
Các rủi ro vận hành là khác nhau.
Một nhóm có thể có thành tích xuất sắc ở một mảng hạ tầng, nhưng vẫn cần chứng minh ở mảng khác.
⚠️ Phân phối tạo ra cơ hội.
Nó không thay thế product-market fit.
Các nhà quản lý kho tiền (vault) theo hướng thể chế vẫn sẽ đánh giá bảo mật.
Các nhà phát hành stablecoin vẫn sẽ đánh giá mức độ tuân thủ.
Các nền tảng RWA vẫn sẽ đánh giá mức linh hoạt của chính sách.
Các ứng dụng AI vẫn sẽ đánh giá độ trễ.
Các nhà phát triển vẫn sẽ hỏi liệu Newton có tạo thêm độ phức tạp vận hành không thể chấp nhận hay không.
Những câu hỏi đó không thể được trả lời chỉ bằng uy tín.
Chúng phải được trả lời bằng cách sử dụng trong môi trường sản xuất.
Một điểm khác thường bị bỏ qua là mức độ đáng tin cậy (credibility).
Hạ tầng ủy quyền tài chính nằm gần khâu thực thi cốt lõi hơn nhiều công cụ dành cho nhà phát triển.
Nếu luồng onboarding ví thất bại, người dùng thường có thể thử lại.
Nếu một lớp ủy quyền hoạt động không như mong đợi, các giao dịch hợp lệ có thể thất bại hoặc giao dịch không hợp lệ có thể được thông qua.
Mức độ khoan dung với các sai sót vận hành sẽ giảm xuống rất nhiều.
Điều đó có nghĩa là niềm tin được tạo dựng theo cách khác.
Không phải thông qua TVL.
Không phải thông qua tương tác trên mạng xã hội.
Thông qua độ uptime.
Hành vi có thể dự đoán được.
Khả năng kiểm toán rõ ràng (clear auditability).
Tài liệu đáng tin cậy.
Logic chính sách minh bạch.
Hỗ trợ linh hoạt (responsive).
Đó không phải là những chỉ số hấp dẫn.
Nhưng đó chính là những chỉ số mà các tổ chức thường quan tâm.
◆ Tôi cũng nghĩ Magic Labs mang đến cho Newton một thứ ít hiển nhiên hơn.
Quan điểm về tính trừu tượng (abstraction).
Hạ tầng tốt nhất thường che giấu sự phức tạp thay vì phơi bày nó.
Bộ SDK ví loại bỏ ma sát (friction) mà không yêu cầu mọi nhà phát triển ứng dụng phải trở thành chuyên gia mật mã (cryptography).
Hạ tầng ủy quyền có thể cần đạt được điều gì đó tương tự.
Các nhà phát triển cần hiểu mô hình bảo mật.
Họ không nên phải trở thành nhà nghiên cứu hệ thống phân tán trước khi gọi một công cụ (policy engine) cho chính sách.
Sự cân bằng đó rất khó.
Quá nhiều lớp trừu tượng tạo ra niềm tin mù quáng.
Quá nhiều phức tạp sẽ ngăn cản việc tiếp nhận.
Newton sẽ cần đứng ở đâu đó giữa hai thái cực đó.
Và có lẽ đó là nơi lịch sử sản phẩm của Magic trở nên liên quan.
Không phải vì nó đảm bảo thành công.
Bởi vì điều đó cho thấy nhóm có kinh nghiệm chuyển đổi hạ tầng khó khăn thành thứ mà nhà phát triển sẵn sàng sử dụng.
Vẫn còn một chặng đường dài phía trước.
Lớp ủy quyền phải chứng minh được giá trị dưới lưu lượng sản xuất.
Các nhà vận hành cần duy trì độ tin cậy.
Việc ghép (composition) chính sách phải vẫn dễ hiểu.
Các nhà cung cấp dữ liệu bên ngoài phải hoạt động nhất quán.
Độ trễ phải vẫn ở mức chấp nhận được.
Cần có động lực kinh tế khi giá trị mạng lưới tăng lên.
Những thách thức đó độc lập với việc ai đã xây dựng giao thức.
Nhưng chính họ quyết định hạ tầng sẽ trở nên thiết yếu hay chỉ là tùy chọn.
Vì vậy tôi nghĩ việc chỉ tập trung vào những người hậu thuẫn (backers) của Newton sẽ bỏ lỡ bức tranh lớn hơn.
Vốn giúp xây dựng công nghệ.
Việc nhà phát triển có áp dụng hay không sẽ quyết định công nghệ đó trở thành hạ tầng hay chỉ là tùy chọn.
Đóng góp thật sự của Magic Labs có thể không nằm ở mức độ đáng tin cậy của lịch sử gây quỹ.
Có thể là hàng năm trời tìm hiểu cách các nhà phát triển quyết định phần nào của hạ tầng xứng đáng có chỗ đứng lâu dài trong ứng dụng của họ.
Và trong hạ tầng, quyết định đó thường đáng giá hơn nhiều so với một logo khác nữa trên trang đối tác.