Tornado Cash và bài toán pháp lý: Khi viết code trở thành tội phạm

Mỗi lần kiểm toán, tôi đều đặt câu hỏi: 'Ai sẽ chịu trách nhiệm nếu dòng code này bị dùng vào mục đích xấu?' Câu hỏi tưởng chừng lý thuyết, nhưng năm 2022, nó trở thành hiện thực đau đớn. Một lập trình viên mã nguồn mở – Alexey Pertsev – bị bắt vì viết code cho Tornado Cash. Không phải vì anh ta hack, không phải vì anh ta rửa tiền. Chỉ đơn giản: anh ta viết một công cụ cho phép người dùng ẩn danh. Và giờ, cả thế giới blockchain đang đặt câu hỏi: 'Liệu tôi có bị bắt vì dòng code tôi viết hôm qua không?' Tôi không tin vào “trách nhiệm hình sự lan tỏa”, tôi tin vào trách nhiệm dựa trên hành vi cụ thể. Nhưng lệnh trừng phạt Tornado Cash đã tạo ra một tiền lệ nguy hiểm: viết code có thể bị coi là đồng phạm. Hãy nhìn vào kỹ thuật: Tornado Cash là một hợp đồng thông minh trên Ethereum, sử dụng zk-SNARKs để che giấu lịch sử giao dịch. Về mặt lập trình, nó là một bộ trộn (mixer) – một ứng dụng phi tập trung không khác gì Uniswap về mặt kiến trúc. Sự khác biệt duy nhất là mục đích sử dụng. Và vì một số người dùng đã dùng nó để rửa tiền (như vụ hack 600 triệu USD từ Axie Infinity), Mỹ đã trừng phạt toàn bộ giao thức. Không chỉ đóng băng địa chỉ – mà còn truy tố người tạo ra. Context: OFAC (Văn phòng Kiểm soát Tài sản Nước ngoài) đã thêm Tornado Cash vào danh sách SDN vào tháng 8/2022. Điều này có nghĩa: bất kỳ ai tương tác với hợp đồng Tornado Cash đều có thể bị phạt hoặc truy tố. Nhưng vấn đề là: hợp đồng thông minh không thể tự sửa đổi. Code là luật. Sau lệnh trừng phạt, các validator của Ethereum vẫn phải xử lý giao dịch liên quan đến Tornado Cash – vì đó là block hợp lệ. Nếu họ từ chối, họ vi phạm quy tắc đồng thuận. Nhưng nếu họ chấp nhận, họ có thể bị coi là vi phạm lệnh trừng phạt. Một cái bẫy kỹ thuật – pháp lý kép. Core phân tích: Khi kiểm tra mã nguồn của Tornado Cash (phiên bản v1.0), tôi thấy một điều thú vị: hợp đồng không có cơ chế “kill switch” hay “whitelist”. Nhà phát triển đã cố tình thiết kế nó phi tập trung – không ai có thể kiểm soát quỹ. Đây là lựa chọn kỹ thuật, không phải sơ suất. Nhưng từ góc độ pháp lý, chính việc này lại trở thành “bằng chứng” rằng nhà phát triển “cố ý tạo ra công cụ không thể kiểm soát để hỗ trợ hoạt động phạm tội”. Tôi không tin vào suy diễn đó. Một hệ thống không có backdoor là một hệ thống an toàn. Nếu bạn coi đó là tội phạm, thì mọi ứng dụng phi tập trung đều có thể bị xử lý. Hãy nhìn vào Uniswap: nếu ai đó dùng Uniswap để swap tiền từ vụ hack, liệu Hayden Adams có bị bắt không? Hay MakerDAO – nếu ai đó dùng DAI để rửa tiền? Ranh giới rất mong manh. Contrarian: Điều trớ trêu là lệnh trừng phạt Tornado Cash không hề ngăn được rửa tiền. Sau khi bị cấm, hacker chuyển sang các mixer khác – như Sinbad.io, hay các cầu nối cross-chain. Thậm chí, họ còn dùng chính Tornado Cash thông qua các private mempool (Flashbots) để tránh bị phát hiện. Thực tế, lệnh trừng phạt chỉ làm tăng chi phí rửa tiền, không loại bỏ nó. Còn với cộng đồng mã nguồn mở, hậu quả là khủng khiếp: các nhà phát triển bắt đầu tự kiểm duyệt. Nhiều dự án DeFi thêm cơ chế “block address” để tránh rủi ro. Tính chất “không cần cấp phép” của blockchain đang bị bào mòn. Tôi tin vào một nguyên tắc: code là luật, nhưng oracle có thể sai. Trong trường hợp này, oracle của OFAC đã sai. Họ trừng phạt một công cụ, không phải một hành vi. Điều đó đặt toàn bộ lập trình viên smart contract vào vòng nguy hiểm. Takeaway: Tương lai, tôi dự đoán sẽ có một cuộc chiến pháp lý về “trách nhiệm của nhà phát triển mã nguồn mở”. Liệu một người viết thư viện mã hóa có bị truy tố nếu kẻ xấu dùng nó để hack? Nếu có, chúng ta sẽ thấy một làn sóng di cư của lập trình viên blockchain khỏi Mỹ và EU. Các công ty công nghệ sẽ phải đặt câu hỏi: liệu có nên tạo ra những công cụ quá mạnh không? Hay chúng ta đang quay lại thời kỳ “súng đạn” – nơi người bán súng bị kiện vì tội giết người? Tôi không có câu trả lời. Nhưng với tư cách một kỹ sư, tôi biết: mỗi lần kiểm toán, tôi đều đặt câu hỏi đó. Và tôi chưa thấy câu trả lời nào từ tòa án.