EthanValeX

Tối thứ Bảy tuần trước, tôi so giá một token trên Binance và CoinMarketCap, rồi thấy hai bên lệch nhau một chút.
Không nhiều.
Chỉ đủ để tôi tự hỏi: nếu một hệ thống dùng dữ liệu đó để quyết định một giao dịch lớn, thì lệch bao nhiêu mới được xem là bình thường?
Vài hôm sau, đọc phần Consensus & Security trong docs của Newton Protocol, tôi dừng ở một error nhỏ.
ToleranceExceeded
Ban đầu, tôi nghĩ đây chỉ là một lỗi kỹ thuật.
Một operator fetch dữ liệu quá lệch so với median. Hệ thống báo lỗi. Builder kiểm tra lại API, tăng tolerance, hoặc đổi data source.
Nhìn qua thì giống chuyện vận hành oracle.
Nhưng càng nghĩ, tôi càng thấy chi tiết này nói nhiều hơn về cách @NewtonProtocol nhìn consensus trên offchain data.
Khi nhiều AVS Operators cùng fetch một dữ liệu ngoài đời, kết quả gần như không bao giờ giống tuyệt đối. Giá token có thể thay đổi từng giây. API này update nhanh hơn API kia. Một endpoint có thể cache chậm hơn vài block.
Nếu bắt mọi operator trả về cùng một giá trị chính xác tuyệt đối, consensus rất dễ gãy.
Nhưng nếu quá dễ dãi, một giá trị lệch mạnh vẫn có thể đi vào policy evaluation như thể nó bình thường.
Newton chọn một đường ở giữa.
Operators fetch dữ liệu độc lập. Gateway tính median cho numeric fields. Nếu các giá trị vẫn nằm trong tolerance, hệ thống có thể đưa chúng về một canonical value để operators cùng evaluate policy trên cùng một nền dữ liệu.
Phần làm tôi chú ý nằm ở trường hợp ngược lại.
Nếu một operator trả về value vượt quá ngưỡng sai khác cho phép, docs không mô tả nó như một thứ bị âm thầm loại bỏ để phần còn lại tiếp tục chạy. Hệ thống có thể fail với ToleranceExceeded.
Outlier không bị lặng lẽ biến mất.
Nó trở thành một trạng thái mà hệ thống buộc phải nhìn thấy.
Điểm này quan trọng hơn tôi nghĩ lúc đầu.
Trong nhiều hệ thống dữ liệu, outlier thường bị xem như noise. Bỏ nó ra, lấy giá trị trung tâm, rồi tiếp tục. Cách đó tiện, nhưng cũng có một rủi ro: nó có thể biến một bất thường thật thành một chi tiết bị che đi.
Có thể API chậm.
Có thể thị trường biến động mạnh.
Có thể một data source đang sai.
Cũng có thể operators không còn đang nhìn vào cùng một thực tại dữ liệu nữa.
Nếu hệ thống vẫn cố ép các giá trị đó thành consensus, policy decision bên trên có thể trông hợp lệ, nhưng nền dữ liệu bên dưới đã không còn ổn.
Đó là lúc tôi thấy ToleranceExceeded không chỉ là lỗi.
Nó là một boundary.
Newton không chỉ hỏi operators có thể đồng thuận hay không. Nó còn hỏi dữ liệu lệch đến mức nào thì hệ thống không nên ép chúng thành một sự đồng thuận giả.
Nhìn theo góc đó, tolerance không chỉ là một con số cấu hình.
Nó là mức sai khác mà Newton còn sẵn sàng xem là cùng một decision context.
Thấp quá thì hệ thống dễ nghẽn vì dữ liệu ngoài đời luôn có noise. Cao quá thì những lệch lạc nguy hiểm có thể bị coi là chấp nhận được.
Tradeoff nằm ở đó.
Một policy có thể viết rất đúng. Một attestation có thể được ký rất đẹp. Nhưng nếu dữ liệu đi vào policy đã lệch quá xa, kết quả cuối cùng vẫn không đáng tin.
Với tôi, giá trị của chi tiết này không nằm ở việc Newton luôn tạo được consensus.
Mà nằm ở việc Newton biết khi nào không nên tạo consensus.
Có lẽ ToleranceExceeded không chỉ nói rằng một operator fetch sai dữ liệu. Nó nói rằng Newton từ chối để policy ra quyết định trên một thực tại mà các operators không còn nhìn giống nhau.
$NEWT $LAB #Newt

Tôi không ngờ rằng tác nhân Mua Theo Lịch Tái Diễn của Newton lại khiến tôi phải suy nghĩ về ranh giới cho phép.
Ban đầu, tôi coi nó như một thiết lập DCA thông thường: chọn tài sản, đặt số tiền, chọn chu kỳ, xác nhận và để hệ thống chạy ở chế độ nền. Luồng này đã rất quen thuộc với bất kỳ ai từng dùng các lệnh mua định kỳ trên sàn, trong một ứng dụng ví, hoặc thông qua một bot đơn giản. Bản thân việc thiết lập cũng không có cảm giác như đang cố gắng chứng minh một luận điểm mang tính “tác nhân tương lai”, và thành thật mà nói, điều đó khiến trải nghiệm trở nên bình thường hơn so với những gì tôi kỳ vọng.

Hôm trước, lục Google Drive để tìm một file khác, tôi lại thấy mấy file KYC cũ vẫn nằm đó.
Ảnh giấy tờ, thông tin cá nhân, mấy file từng upload cho một app nào đó mà chính tôi cũng không còn dùng nữa.
Lúc đó tôi mới nghĩ: dữ liệu riêng tư đáng sợ không chỉ vì nó có thể bị lộ.
Nó còn đáng sợ vì nó sống quá lâu.
Vài hôm sau, đọc lại phần Privacy Layer trong docs của Newton Protocol, tôi dừng ở một field rất nhỏ.
ttl
Ban đầu, tôi nghĩ đây chỉ là một tham số kỹ thuật để hệ thống biết khi nào nên xóa encrypted data reference.
Người dùng upload dữ liệu đã mã hóa. Newton trả về một reference ID. Sau đó ttl quyết định reference đó còn sống trong bao lâu.
Nhìn qua thì giống một cơ chế cleanup khá bình thường.
Nhưng càng nghĩ, tôi càng thấy field này đang bảo vệ một thứ sâu hơn storage.
Nó bảo vệ tuổi thọ của đường quay lại dữ liệu riêng tư.
Trong @NewtonProtocol , dữ liệu nhạy cảm không được đưa thẳng lên onchain. Người dùng mã hóa dữ liệu ở phía client, task chỉ mang theo encrypted data references, còn operator chỉ decrypt trong quá trình policy evaluation khi đúng authorization context.
Điều đó khiến tôi ban đầu tập trung vào encryption.
Ai được đọc dữ liệu?
Ai không được đọc?
Plaintext có bị lộ onchain không?
Nhưng ttl làm tôi đổi câu hỏi.
Vấn đề không chỉ là ai có thể đọc dữ liệu. Vấn đề còn là hệ thống được phép giữ một đường dẫn quay lại dữ liệu đó trong bao lâu.
Reference ID không phải secret. Nó không tự tiết lộ plaintext. Nhưng nó vẫn là một handle trỏ tới một future decryption path. Khi reference đó còn valid, encrypted material vẫn còn tồn tại như một thứ có thể được dùng lại nếu đúng flow xuất hiện.
Đó là lúc tôi mới thấy TTL không chỉ là expiration.
Nó là lifetime boundary của capability.
Nếu không có TTL, một encrypted reference có thể dần biến thành một capability dài hạn bên trong authorization system. Dữ liệu có thể vẫn được mã hóa, nhưng đường quay lại dữ liệu đó vẫn tiếp tục sống.
Newton Protocol dường như đang cố cắt ngắn vòng đời đó.
Private data không chỉ được bảo vệ bằng encryption. Nó còn bị giới hạn thời gian tồn tại như một operational resource.
Một KYC document, portfolio snapshot, private credential hay risk input có thể cần thiết cho một policy decision cụ thể. Nhưng điều đó không có nghĩa reference của nó nên tiếp tục sống mãi sau khi task đã đi qua.
Nhìn theo góc đó, ttl không chỉ trả lời câu hỏi dữ liệu được lưu bao lâu.
Nó trả lời câu hỏi một authorization flow được phép giữ capability quay lại dữ liệu riêng tư trong bao lâu.
Tất nhiên, tradeoff vẫn còn đó.
TTL quá ngắn thì legitimate execution có thể fail trước khi user hoàn tất flow. TTL quá dài thì hệ thống giữ đường quay lại sensitive material lâu hơn nhu cầu thật sự của task.
Nhưng chính tradeoff đó làm field này đáng chú ý.
Với tôi, ttl cho thấy privacy trong Newton Protocol không chỉ là mã hóa dữ liệu. Nó còn là việc giới hạn vòng đời của khả năng sử dụng lại dữ liệu đó.
Có lẽ dữ liệu riêng tư không nên chỉ được hỏi là có được encrypt hay chưa.
Nó cũng cần được hỏi: nó còn được phép sống bao lâu trong hệ thống?
$NEWT $LAB #Newt

Hôm trước, ngồi ở quán cà phê đối diện tiệm photocopy gần nhà, tôi mở docs của Newton Protocol và đọc lại phần Consensus & Security.
Có một chi tiết làm tôi dừng lại khá lâu.
Newton không chỉ tạo một digest.
Nó tách thành hai digest.
Ban đầu tôi nghĩ đây chỉ là chuyện kỹ thuật của chữ ký. Một hệ thống có nhiều AVS Operator, BLS aggregation, ECDSA attestation và onchain verification thì việc có nhiều hash trung gian cũng không quá lạ. Đọc lướt qua, chi tiết này rất dễ bị xem như phần implementation.
Nhưng càng nhìn kỹ, tôi càng thấy @NewtonProtocol đang xử lý một mâu thuẫn sâu hơn trong cách một authorization layer nên lưu lại sự đồng thuận.
Vấn đề nằm ở chỗ BLS aggregation cần sự đồng nhất tuyệt đối.
Nếu nhiều operator cùng ký một authorization, hệ thống không thể để mỗi operator ký một message hơi khác nhau. Chỉ cần object được ký lệch đi ở một field, aggregate signature không còn đại diện cho một agreement chung nữa. Nó chỉ còn là nhiều chữ ký được gom lại, nhưng không còn chắc rằng tất cả đang chỉ về cùng một điều.
Đó là lý do Consensus Digest tồn tại.
Consensus Digest giữ phần cần giống nhau để các operator cùng ký. Những dữ liệu riêng của từng operator, như ECDSA attestation riêng, không được đưa vào digest này. Nếu đưa vào, mỗi operator sẽ tạo ra một object khác nhau, và collective agreement sẽ mất điểm neo chung trước khi nó kịp được aggregate.
Lúc đầu, tôi thấy phần này khá dễ hiểu.
Nhưng nếu Newton chỉ cần một chữ ký tổng hợp, câu chuyện đã dừng ở đó.
Điểm khó là một authorization layer không chỉ cần biết “đã có đủ operator đồng ý chưa.” Nó còn cần giữ đủ bằng chứng để sau này có thể kiểm tra lại decision đó. Khi có challenge, câu hỏi không còn đơn giản là quorum đã đủ hay chưa. Câu hỏi trở thành: hệ thống còn lưu đủ record để chứng minh từng phần của decision đã được tạo ra như thế nào không?
Đây là nơi Full Digest bước vào.
Full Digest giữ phần đầy đủ hơn, bao gồm cả các attestation riêng của operator, để phục vụ contract storage và challenge verification. Nó không tối ưu cho việc mọi operator cùng ký một message giống nhau. Nó tối ưu cho việc hệ thống không đánh mất bằng chứng sau khi agreement đã xảy ra.
Đến đây tôi mới thấy Two-Digest Design không chỉ là cách làm cho BLS hoạt động.
Nó là cách Newton tách hai loại dữ liệu thường bị trộn lẫn.
Một loại dữ liệu cần được làm phẳng để nhiều operator có thể cùng ký.
Một loại dữ liệu cần được giữ đầy đủ để nếu có tranh chấp, hệ thống vẫn còn đủ thứ để bị chất vấn.
Hai nhu cầu này nghe gần nhau, nhưng thật ra kéo kiến trúc theo hai hướng khác nhau. Consensus cần sự đồng nhất. Accountability cần sự đầy đủ. Nếu ép cả hai vào cùng một digest, hệ thống phải hy sinh một trong hai.
Nếu chỉ dùng Consensus Digest, chữ ký tổng hợp có thể sạch hơn, nhưng phần evidence phía sau có nguy cơ bị nén quá mức. Khi cần challenge, record còn lại có thể không đủ giàu để trả lời câu hỏi operator nào đã tạo ra attestation nào.
Nếu chỉ dùng Full Digest, hệ thống giữ được nhiều evidence hơn, nhưng lại làm hỏng điều kiện cơ bản của BLS aggregation: tất cả operator phải ký cùng một message.
Newton không cố làm một digest gánh cả hai vai trò.
Với tôi, đây là điểm đáng chú ý.
Trong nhiều hệ thống crypto, chữ ký thường được xem như dấu chấm hết của một quyết định. Có đủ chữ ký là xong. Có quorum là xong. Có proof onchain là xong.
Nhưng với một onchain authorization layer, chữ ký không nên biến decision thành hộp đen. Nó phải vừa giúp transaction đi tiếp, vừa để lại đủ dấu vết để decision đó có thể bị kiểm tra lại nếu cần.
Nhìn theo góc đó, Two-Digest Design không chỉ là chuyện hash.
Nó là một cách phân tầng trách nhiệm.
Consensus Digest bảo vệ sự đồng nhất của agreement.
Full Digest bảo vệ khả năng truy lại evidence.
Một bên giúp hệ thống đạt đồng thuận.
Một bên giúp đồng thuận đó không trở thành kết luận không thể chất vấn.
Có lẽ đó là phần sâu nhất của thiết kế này.
Agreement giúp transaction đi tiếp.
Evidence giúp agreement không biến thành hộp đen.
$NEWT $LAB #Newt

Một phương thức SDK nhỏ đã khiến tôi suy nghĩ lại về cách danh tính nên “thoát ra”/được xử lý như thế nào.
Ban đầu, unlinkApp trông có vẻ chỉ là một phần nhỏ trong luồng danh tính của Newton.
Liên kết linkApp của Newton liên kết danh tính đã đăng ký của người dùng với một hợp đồng máy khách chính sách (policy client) cụ thể. Lời gọi này không chỉ là một lần đăng nhập chung chung. Nó bao gồm địa chỉ ví dApp của người dùng, địa chỉ hợp đồng policy client đã triển khai và một miền danh tính như giá trị băm của “kyc”.
Chi tiết đó quan trọng.
Liên kết này cho lớp danh tính biết danh tính người dùng nào, hợp đồng ứng dụng nào và miền danh tính nào thuộc về nhau để phục vụ đánh giá chính sách sau này. Khi đã được thiết lập, công cụ chính sách của Newton có thể truy cập dữ liệu KYC đã đăng ký khi các tác vụ được gửi thông qua policy client đó.

Trước đây tôi từng nghĩ dữ liệu được mã hóa là dữ liệu an toàn.
Nhưng đó chỉ là một nửa sự thật.
Mã hóa ẩn thông tin khỏi công chúng. Nó giữ dữ liệu cá nhân thô tránh xa khỏi chuỗi và tránh xa khỏi các bảng điều khiển (dashboards). Với một lớp ủy quyền trên chuỗi (onchain) như @NewtonProtocol , điều đó rất quan trọng, đặc biệt khi Newton Mainnet Beta tiến về việc kiểm tra chính sách trước khi thanh toán (settlement).
Nhưng quyền riêng tư không kết thúc khi dữ liệu được mã hóa.
Câu hỏi khó hơn là điều gì xảy ra khi hệ thống cần sử dụng lại dữ liệu đó.
Đó là nơi thiết kế quyền riêng tư của Newton trở nên thú vị hơn đối với tôi. Giao thức không chỉ tìm cách giữ thông tin nhạy cảm bên ngoài chuỗi (offchain). Nó còn cố gắng kiểm soát thời điểm để thông tin đã được mã hóa trở nên có thể đọc được bên trong quá trình đánh giá chính sách.

Newton giải quyết một vấn đề thực tế cho DeFi được quản lý, nhưng tôi nghĩ phần quan trọng còn hẹp hơn so với cách giới thiệu thông thường về “lớp tuân thủ”. Câu hỏi then chốt không phải là liệu Newton có thể tạo ra một chứng thực (attestation) hay không. Câu hỏi khó hơn là liệu chứng thực đó có bắt buộc phải nằm trong đường thực thi hay không.
Sự phân biệt đó quan trọng.
Một giao thức có thể có các báo cáo tuân thủ. Nó có thể có việc sàng lọc ví. Nó có thể có các bảng điều khiển giám sát. Nó thậm chí có thể có các chứng thực đã được ký. Nhưng nếu một hợp đồng thông minh vẫn có thể thực thi mà không phụ thuộc vào chứng thực đó, thì việc tuân thủ vẫn mang tính khuyến nghị chứ không phải có thể cưỡng chế.

tôi cứ nghĩ ít hơn về chính bản thân tác nhân AI, và nhiều hơn về ranh giới quyền hạn xung quanh nó.
Điều đó giống như phần quan trọng hơn nhiều ở @NewtonProtocol .
Một tác nhân AI có thể giao dịch, tái cân bằng, chuyển tiếp, hoặc thực hiện các hành động on-chain nghe có vẻ hữu ích. Nhưng hữu ích không đồng nghĩa với kiểm soát. Ngay khi một tác nhân được kết nối với tài sản thực, câu hỏi khó không còn là liệu nó có thể hành động hay không.
Câu hỏi khó là nó được phép làm gì.
Thiết kế của Newton dường như tập trung vào ranh giới đó. Thay vì coi tự động hóa như một phê duyệt rộng, một hành động sẽ được đối chiếu với chính sách trước khi thực thi. Nếu hành động phù hợp với chính sách, nó có thể tiến lên với một bản xác nhận. Nếu không phù hợp, giao dịch nên bị dừng trước khi tài sản được di chuyển.

Tối thứ Năm tuần trước, mình gặp Hưng, một người bạn đang làm compliance cho một app lending. Lúc mình tới, nó đang nhìn một file Excel tên “Enhanced Due Diligence - High Risk Users”. Mình liếc qua tiêu đề rồi đùa:
“File này chắc không dùng để chúc mừng khách hàng ha?”
Hưng cười, nhưng kiểu cười của người hơi đuối.
Trên màn hình là một loạt cột nhìn thôi đã thấy mệt: source of funds, wallet history, IP country, occupation, monthly income, sanctions flag.
Mình hỏi:
“Cần nhiều thứ vậy luôn hả?”
Hưng nói:
“Cần. Nhưng càng cần thì càng sợ.”
Mình hỏi sợ gì. Nó chỉ vào màn hình rồi nói: “Thông tin khách hàng là thứ công ty nào cũng muốn có, nhưng không ai thật sự muốn chịu trách nhiệm giữ nó.”
Lúc đó mình chỉ nghĩ fintech thì phải vậy. Làm tài chính mà không xác minh thì khác gì mở cửa kho tiền rồi mong mọi người tự tử tế. Nhưng trên đường về, câu “càng cần thì càng sợ” cứ nằm mãi trong đầu.
Điều khó chịu của compliance không chỉ là nó hỏi nhiều.
Mà là mỗi lần hỏi thêm một chút, hệ thống lại giữ thêm một mảnh đời tư của người dùng.
Đến khi đọc về Verifiable Credentials và privacy layer của @NewtonProtocol , mình lại nhớ tới cuộc nói chuyện hôm đó.
Ban đầu mình cứ nghĩ một authorization layer chắc sẽ khiến protocol biết nhiều hơn về user. Muốn biết ai đủ điều kiện giao dịch, ai không nằm trong sanctions list, ai thuộc khu vực được phép, ai là accredited investor… nghe qua đã thấy rất nhiều dữ liệu.
Nhưng điểm thú vị lại nằm ở hướng ngược lại.
Newton không cố làm compliance bằng cách bắt hệ thống biết mọi thứ.
Newton đang thử làm cho hệ thống biết vừa đủ để ra quyết định, nhưng không biết quá nhiều đến mức chính nó trở thành rủi ro.
Đây là chỗ Verifiable Credentials đáng chú ý. Thay vì mỗi app bắt người dùng nộp lại giấy tờ từ đầu, credential cho phép họ giữ bằng chứng của mình và chỉ trình ra đúng thuộc tính cần thiết.
Tôi đã KYC.
Tôi không nằm trong danh sách bị chặn.
Tôi đủ điều kiện tham gia sản phẩm này.
Vậy là đủ.
Không cần biến cả danh tính thành một tập hồ sơ nằm rải rác ở mười nền tảng khác nhau.
Newton Identity Oracle đi theo logic đó: issuer phát hành credential, người dùng giữ, verifier kiểm tra bằng chứng, còn smart contract cuối cùng chỉ cần biết policy pass hay fail. Nó không cần đọc toàn bộ câu chuyện phía sau.
Mình gọi vấn đề này là Data Liability.
Dữ liệu không chỉ là tài sản.
Dữ liệu còn là khoản nợ trách nhiệm.
Một app càng giữ nhiều thông tin nhạy cảm, nó càng có nhiều thứ để mất khi bị leak, bị lạm dụng hoặc bị dùng sai ngữ cảnh. Nhiều dự án nghĩ thu thập thêm dữ liệu là tăng khả năng kiểm soát, nhưng đôi khi đó chỉ là làm quả bom dưới ghế mình to hơn.
Điểm mình thích ở Newton là hướng thiết kế privacy khá rõ: blockchain không cần nhìn thấy danh tính gốc, mà chỉ cần thấy proof, attestation hoặc kết quả policy đã được kiểm. Còn những phần như selective disclosure, privacy envelope hay các hướng mã hóa sâu hơn nên được nhìn đúng bản chất: đây là nỗ lực giảm lượng dữ liệu phải phơi ra, không phải lời hứa rằng mọi bài toán riêng tư đã được giải xong.
Mình không muốn lãng mạn hóa đoạn này.
Bài toán rất khó. Regulator cần auditability. Tổ chức cần risk control. Người dùng cần quyền riêng tư. DeFi protocol cần composability. Newton đang cố đứng giữa những nhu cầu kéo nhau về nhiều hướng, mà đứng giữa luôn là vị trí dễ bị xé nhất.
Nói privacy thì ai cũng thích, nhưng tới lúc build thật lại có nhiều thứ rất thực dụng. Nếu tích hợp quá nặng, nếu user phải chờ lâu, nếu developer phải hiểu thêm quá nhiều lớp mới, nhiều app có thể quay lại dùng một compliance provider tập trung cho nhẹ đầu.
Lúc đó Newton không thua vì chọn sai vấn đề.
Mà vì vấn đề đúng nhưng quá khó để đưa vào thói quen của builder.
Với $NEWT , mình sẽ không chỉ nhìn số lần được nhắc tên. Mình muốn nhìn credential checks thật, policy calls thật, compliance receipts thật và những app thật sự cần private authorization trước settlement.
Vì xác minh tốt không phải là hỏi nhiều hơn.
Mà là hỏi ít hơn, nhưng đúng hơn.
Và privacy tốt không phải là che mọi thứ.
Mà là để hệ thống đủ thông tin để quyết định…
nhưng không đủ để làm hại con người.
Vì trong tài chính onchain, quyền riêng tư không nên là phần thưởng cho người trốn kiểm tra.
Nó phải là tiêu chuẩn cho cả những người đã được kiểm tra.
Một hệ thống tốt không cần biết hết về bạn để quyết định bạn có được đi tiếp hay không.
Nó chỉ cần biết đúng điều cần biết.
$NEWT #Newt $TAIKO