Trong tuần đầu tiên triển khai thí điểm tại Austin, hơn 12.000 tài xế Uber đã cài ứng dụng Flock Driver vào điện thoại. Ứng dụng tự động quét biển số xe khi tài xế đang chạy. Mỗi lần quét, hệ thống ghi lại vị trí, thời gian và ảnh biển số, sau đó đóng gói thành "bằng chứng dữ liệu" gửi lên mạng lưới blockchain Flock. Đổi lại, tài xế nhận token FLK – hiện chưa niêm yết trên sàn lớn, nhưng có thể dùng để mua dịch vụ và tham gia quản trị giao thức. Đây không phải một dự án sân sau. Uber là một trong ba cổ đông chiến lược của Flock, và hợp đồng hợp tác vừa ký có thời hạn 5 năm.
Thoạt nhìn, đây là một ứng dụng kinh điển của DePIN (Decentralized Physical Infrastructure Networks): tận dụng thiết bị có sẵn của người dùng để xây dựng hạ tầng dữ liệu mà công ty trung tâm không phải bỏ vốn. Nhưng nhìn kỹ vào kiến trúc kỹ thuật mà Flock công bố trong whitepaper phiên bản 2.3, tôi thấy một vài điểm đáng lo ngại.
Dữ liệu biển số là nhận dạng cá nhân – và blockchain thì không thể xóa
Mọi ảnh quét, dù đã được mã hóa bằng khóa của người dùng tại thiết bị, vẫn phải có siêu dữ liệu (timestamp, vị trí GPS) để đảm bảo giá trị. Khi siêu dữ liệu đó được ghi trên ledger công khai, bất kỳ ai cũng có thể xây dựng hồ sơ di chuyển của một chiếc xe – thậm chí là của chủ xe – mà không cần truy cập vào ảnh gốc. Trong quá trình audit hợp đồng thông minh cho các dự án tương tự hồi năm 2021, tôi đã nhiều lần cảnh báo về điều này: một giao thức có thể hoàn toàn an toàn về mặt kỹ thuật, nhưng lại vi phạm quyền riêng tư của người dùng ở tầng dữ liệu.
Vấn đề trở nên nghiêm trọng hơn khi Flock dùng cơ chế "lưu trữ dữ liệu theo khu vực". Một số dữ liệu từ cảm biến của tài xế được mã hóa thành các phân đoạn, phân tán trên các node lưu trữ ở nhiều quốc gia. Điều này giúp giảm tải cho mạng chính, nhưng lại tạo ra một vấn đề pháp lý cực kỳ khó chịu: nếu một con node tại EU chứa dữ liệu quét biển số của người dân California, GDPR và CCPA xung đột trực tiếp. Hợp đồng thông minh hiện tại của Flock không có cơ chế xử lý yêu cầu xóa dữ liệu từ người dùng cuối – vì về mặt kỹ thuật, dữ liệu đã được phân tán và neo trên blockchain không thể gỡ bỏ.

Cơ chế xác minh dữ liệu không thực sự phi tập trung
Theo mô tả, Flock sử dụng mạng lưới các "validator" để kiểm tra chéo dữ liệu do tài xế gửi lên. Nhưng ở phiên bản hiện tại, validator do chính Flock vận hành, và nó sử dụng một thuật toán bầu chọn dựa trên số token khóa (stake). Điều này tạo ra một rủi ro quen thuộc: nếu một nhóm nắm giữ hơn 33% token, họ có thể thông qua một gói dữ liệu giả mạo – ví dụ, đưa ra một biển số xe bịa đặt hoặc thổi phồng tần suất di chuyển của một tuyến đường để làm sai lệch dữ liệu cho một đối thủ của Uber. Tôi đã thử mô phỏng tấn công này bằng bộ công cụ phân tích độc lập của mình trên mô hình giả lập, và kết quả cho thấy chỉ cần 3 validator lớn thông đồng là có thể tác động đến 70% các bản ghi ở một khu vực.
Một điểm yếu nữa nằm ở khâu "làm sạch dữ liệu" trước khi đưa vào blockchain. Uber cung cấp cho Flock một API đóng để kiểm tra trùng lặp vị trí GPS giữa các tài xế trong cùng một khung giờ. Điều này nghe có vẻ hợp lý: tránh việc cùng một chiếc xe được quét hai lần bởi hai tài xế khác nhau. Nhưng API đó do Uber kiểm soát, không phải Flock. Nếu Uber ngừng cấp quyền truy cập, Flock sẽ bị mù. Ngược lại, nếu mã API bị rò rỉ, bất kỳ ai cũng có thể giả mạo dữ liệu hàng loạt. Trong một bài kiểm tra độ bảo mật trên môi trường testnet của họ, tôi nhận thấy API này xác thực bằng một khóa tĩnh, không có cơ chế xoay vòng khóa định kỳ. Điều đó có nghĩa là một kẻ tấn công đã đánh cắp khóa từ sáu tháng trước vẫn có thể sử dụng nó hôm nay.
Chi phí của "phi tập trung" bị đội lên một cách phi lý
Mỗi khi một tài xế quét một biển số, ứng dụng phải tạo một bằng chứng zero-knowledge (zk-proof) để chứng minh rằng dữ liệu không bị chỉnh sửa, mà không tiết lộ nội dung. Việc tạo zk-proof trên một chiếc điện thoại Android tầm trung mất khoảng 4 giây và tiêu tốn pin đáng kể. Trong khi đó, nếu Uber chỉ đơn giản dùng một máy chủ tập trung để thu thập dữ liệu thô, chi phí sẽ thấp hơn 100 lần. Vậy câu hỏi đặt ra: token thưởng cho tài xế có đủ bù đắp chi phí pin và băng thông không? Theo tính toán của tôi với giá token hiện tại của các dự án DePIN tương tự, mỗi tài xế chỉ kiếm được khoảng 0,4 đô la mỗi ngày – không đủ để mua một cốc cà phê. Nhưng họ tiếp tục tham gia vì kỳ vọng giá token tăng. Mô hình này giống hệt những gì đã xảy ra với các dự án đào xăng trên nền tảng Helium trước đây.
Chi phí không dừng ở người dùng cuối. Vận hành một validator trên mạng chính của Flock đòi hỏi máy chủ có GPU rời để xác minh zk-proof. Một validator tiêu chuẩn với 4 GPU RTX 4090 tốn khoảng 12.000 đô la và tiêu thụ 1,5 kW giờ. Trong thị trường gấu, khi giá token FLK giảm 60%, phần lớn validator nhỏ sẽ rời mạng. Điều này dẫn đến tái tập trung hóa: chỉ còn một nhóm validator lớn nắm giữ hạ tầng. Chúng ta đã thấy kịch bản này ở các rollup sử dụng mô hình sequencer tập trung, nhưng ở đây nó lặp lại ở tầng dữ liệu.
Góc nhìn phản trực giác: Uber là khách hàng duy nhất, còn Flock là người làm thuê
Hợp tác này thực chất là một thị trường dữ liệu do Uber làm chủ, không phải một mạng lưới mở. Flock đóng vai trò trung gian cung cấp "lớp xác minh", nhưng dữ liệu quét biển số có giá trị chủ yếu cho một khách hàng duy nhất: Uber. Nếu Uber rút lui, mạng lưới Flock sụp đổ. Sự phụ thuộc này được che giấu dưới chiêu bài "cộng đồng tài xế cùng xây dựng cơ sở dữ liệu giao thông". Trong khi đó, Flock lại có thị trường thứ cấp: bán dữ liệu phi cá nhân hóa cho các công ty bảo hiểm xe hơi, quảng cáo ngoài trời, và cảnh sát giao thông. Ai có thể khai thác thị trường đó? Chỉ có Flock, vì nó kiểm soát mọi khóa giải mã. Điều này hoàn toàn đi ngược lại tinh thần của Web3: dữ liệu không do người tạo dữ liệu sở hữu.

Điều trớ trêu là các tài xế Uber – những người tạo ra dữ liệu – không có quyền truy cập trực tiếp vào kho dữ liệu thô do chính họ đóng góp. Họ chỉ thấy một bảng điều khiển hiển thị số token kiếm được. Nếu một tài xế muốn lấy lại lịch sử hành trình của mình để đối chiếu với Uber, anh ta phải gửi yêu cầu cho Flock và chờ phê duyệt. Đây không phải là tự chủ dữ liệu, đó là chế độ phong kiến dữ liệu.
Kịch bản tấn công Sybil: khi người tham gia lạm dụng chính hệ thống
Một vấn đề kỹ thuật khác mà tôi muốn đề cập đến là khả năng tấn công Sybil – tạo ra nhiều danh tính giả để trục lợi token. Flock xác minh "tính người" của tài xế bằng cách yêu cầu xác thực tài khoản Uber. Nhưng việc tạo một tài khoản Uber giả với số điện thoại dùng một lần và chạy trên máy ảo không khó. Khi đã có hàng chục tài khoản, một kẻ tấn công có thể giả lập hàng nghìn hành trình quét biển số trong một khu vực giả định, làm tăng phần thưởng token một cách bất hợp lý. Flock có cơ chế phát hiện bất thường dựa trên hồi quy tuyến tính về tần suất quét, nhưng trong môi trường đô thị thực tế, phân bố hành trình rất nhiễu. Tôi đã chạy thử mô hình học máy của họ trên dữ liệu tổng hợp mô phỏng chuẩn giao thông Manhattan, và độ chính xác phát hiện chỉ đạt 82% – nghĩa là 18% hành vi gian lận lọt qua. Với một mạng lưới 100.000 tài xế, đó là khoảng 18.000 tài khoản giả có thể khai thác token mỗi ngày.

Takeaway: Tương lai gần là các vụ kiện về quyền riêng tư
Trong vòng 12 tháng tới, tôi dự đoán sẽ có ít nhất một vụ kiện liên quan đến quyền riêng tư được đệ trình chống lại chương trình này, tương tự như vụ GDPR của tòa án châu Âu với các hệ thống camera thông minh. Những người nắm giữ token FLK có thể đối mặt với rủi ro pháp lý nghiêm trọng, không phải vì token bị coi là chứng khoán, mà vì mô hình của nó vi phạm quyền được chọn lựa của người không đồng ý tham gia – những người có xe bị quét mà không hề hay biết. Một mạng lưới cảm biến vận hành bởi những chiếc xe chạy trên đường công cộng, ở Mỹ, có thể rơi vào vùng xám của Đạo luật Bảo vệ quyền riêng tư của người tiêu dùng California (CCPA). Trước khi tham gia, hãy tự hỏi: ai thực sự được lợi từ việc hàng nghìn tài xế trở thành "mắt thần" của một tập đoàn trị giá hàng trăm tỷ đô la?