- Turso đã vận hành gần 1 năm chương trình bug bounty trả 1.000 USD cho các lỗi được chứng minh là gây hỏng dữ liệu, và nay quyết định kết thúc
- Khi có tiền thưởng, một lượng lớn PR chất lượng thấp do AI tạo ra đã đổ vào, khiến các maintainer phải mất nhiều ngày chỉ để đóng chúng
- Ban đầu, Turso đã thưởng cho 5 người, và một số đóng góp đã dẫn đến việc cải thiện simulator cũng như phát hiện hơn 10 lỗi trong SQLite
- Turso đã dùng hệ thống bảo chứng để tự động đóng các PR đáng ngờ, nhưng bot vẫn liên tục mở issue yêu cầu rà soát thủ công và gửi lại các PR tương tự
- Để duy trì đóng góp mở, Turso chọn loại bỏ động lực tài chính thay vì đóng hệ thống
Vì sao Turso dừng bug bounty
- Trong gần 1 năm, Turso trả 1.000 USD cho các lỗi được chứng minh có thể dẫn đến hỏng dữ liệu, nhưng hiện đã chấm dứt chương trình
- Sau khi gắn thưởng bằng tiền, kho lưu trữ của Turso bị tràn ngập PR chất lượng thấp do AI tạo ra, đến mức các maintainer phải dành phần lớn thời gian trong nhiều ngày để đóng những PR này
- Turso muốn tiếp tục là một dự án mở cho đóng góp, nhưng cho rằng mô hình trả tiền cho một loại lỗi cụ thể đã khiến việc vận hành đóng góp mở gần như không thể thực hiện được
- Quyết định này được công bố trong nhận thức rằng mọi người cần cùng nhau học cách xây dựng mô hình quản trị mã nguồn mở trong một kỷ nguyên mới
Bối cảnh khởi động chương trình
- Turso đang tái hiện thực SQLite, một phần mềm được xem là thuộc nhóm đáng tin cậy nhất thế giới, nên cần tiêu chuẩn độ tin cậy rất cao
- Để đạt hoặc vượt mức độ tin cậy của SQLite, Turso vận hành nhiều hệ thống kiểm thử
- deterministic simulator native
- nhiều fuzzer
- công cụ kiểm thử vi sai dựa trên oracle để so sánh với SQLite
- simulator đồng thời
- chạy diện rộng trên Antithesis
- Tuy vậy, hạ tầng kiểm thử cuối cùng vẫn là phần mềm nên không thể hoàn hảo, và chỉ có thể bắt được lỗi trong các tổ hợp mà bộ sinh thực sự tạo ra
- Ví dụ, nếu fuzzer không tạo index, thì dù có stress test rất mạnh các phần khác của hệ thống cũng khó tìm ra lỗi liên quan đến index
- Turso từng tìm thấy một lỗi chỉ xuất hiện khi cơ sở dữ liệu lớn hơn 1GB, nhưng vì mỗi lần chạy đều bơm lỗi rất mạnh nên cơ sở dữ liệu không bao giờ lớn tới mức đó, khiến lỗi thoát khỏi simulator
- Điểm mạnh của kiểm thử tự động là ngay cả khi một lỗi từng lọt qua, chỉ cần cải thiện bộ sinh kiểm thử thì có thể loại bỏ cả một lớp lỗi
- Bug bounty vừa là cách Turso thể hiện sự tự tin vào phương pháp kiểm thử của mình, vừa là cơ chế để thưởng cho ai tìm ra những vùng mà simulator chưa bao phủ tốt
- Kế hoạch ban đầu là trả 1.000 USD cho các lỗi hỏng dữ liệu cho tới trước khi Turso 1.0 ra mắt, sau đó sẽ dần mở rộng mức thưởng và phạm vi đối tượng sau 1.0
Hiệu quả trước khi làn sóng gửi nội dung AI chất lượng thấp xuất hiện
- Ở giai đoạn đầu, tổng cộng 5 người đã nhận thưởng và đóng góp có ý nghĩa cho dự án
- Alperen là một trong những người đóng góp cốt lõi cho simulator của Turso và hiểu rõ những điểm có thể cải thiện
- Mikael đã sử dụng LLM một cách sáng tạo để tìm ra những vùng mà simulator không chạm tới, và sau đó được tuyển vào Turso
- Pavan Nambi kết hợp simulator với các kỹ thuật hình thức để tìm ra không chỉ lỗi của Turso mà còn hơn 10 lỗi trong chính SQLite
Gánh nặng vận hành do nội dung do AI tạo ra
- Tiêu chuẩn gửi bài mà Turso mong muốn không chỉ là chỉ ra lỗi đơn thuần, mà là mở rộng simulator để chứng minh lỗi hỏng dữ liệu
- Nhờ điều kiện này, các PR xấu chỉ nhằm săn thưởng ban đầu khá hiếm, và số lỗi hỏng dữ liệu thực sự cũng không nhiều
- Sau đó xuất hiện ồ ạt các bài gửi được tạo bằng cách ra lệnh cho LLM tìm lỗi trong Turso và nhận tiền thưởng
- Khi nhận loại chỉ thị đó, LLM có thể tạo ra đủ loại đầu ra, nhưng việc đầu ra đó có hợp lệ hay không lại là chuyện khác
Các trường hợp gửi chất lượng thấp tiêu biểu
-
PR cố tình làm hỏng header cơ sở dữ liệu bằng tay
- PR #6257 đã tự chèn các byte rác vào header cơ sở dữ liệu rồi tuyên bố rằng cơ sở dữ liệu bị hỏng
- Ngay cả sau khi maintainer chỉ ra đây là kết quả hiển nhiên, người gửi hoặc bot vẫn tiếp tục phản bác bằng những đoạn dài kiểu LLM
-
Bài gửi tự chèn truy cập out-of-bound vào mã nguồn
- Một bài gửi khác đã tự thêm truy cập mảng out-of-bound vào mã nguồn để làm hỏng cơ sở dữ liệu
- Issue liên quan: tursodatabase/turso#5508
-
PR coi việc thực thi SQL là lỗ hổng
- PR #4322 có đầy bảng biểu, dấu check màu xanh lá và em dash, đồng thời tuyên bố đã tìm ra một lỗ hổng nghiêm trọng cho phép thực thi câu lệnh SQL tùy ý
- Turso cho rằng không thể xem việc một cơ sở dữ liệu SQL cho phép thực thi câu lệnh SQL tự thân là một lỗ hổng
-
PR hiểu sai tính năng ghi đồng thời của Turso
- PR #6874 bật ghi đồng thời, một trong những điểm khác biệt của Turso, rồi cho thấy SQLite không thể mở tệp cho tới khi chuyển journal mode trở lại WAL để tắt ghi đồng thời
- Đây là kết quả đúng như hệ thống được thiết kế
-
Bài gửi khó hiểu mục đích
- Một bài gửi khác có nội dung khó xác định là đang muốn làm gì
- Maintainer Mikael nhận định người gửi đã thấy thông báo thưởng và nhắm công cụ AI sinh nội dung vào Turso
Phản ứng cuối cùng: hệ thống bảo chứng
- Turso đã thiết kế và triển khai hệ thống bảo chứng (vouching) như nỗ lực cuối cùng để lập lại trật tự
- Cơ chế này sẽ tự động đóng các bài gửi bị nghi là từ bot, và trong một thời gian nó hoạt động tương đối hiệu quả
- Sau đó, bot bắt đầu mở issue yêu cầu rà soát thủ công để phản đối lý do PR bị đóng
- Khi một PR bị đóng, cùng người dùng đó hoặc người dùng khác cũng nhiều lần mở lại các PR giống hệt hoặc rất tương tự ngay sau đó
Xung đột giữa đóng góp mở và động lực tài chính
- Bên tạo ra các bài gửi chất lượng thấp chỉ mất khoảng 1 phút để tạo một bài, nhưng Turso phải mất hàng giờ để đọc, hiểu và phản hồi
- Những bài gửi này trên thực tế có thể được tạo ra với tốc độ gần như vô hạn
- Có thể xây dựng các hệ thống gác cổng tự động, nhưng khi có phần thưởng tài chính đủ đáng kể thì AI sẽ tiếp tục tranh cãi và mở lại cùng PR, vì động lực vẫn còn rất lớn
- Turso coi trọng cộng đồng đóng góp mã nguồn mở và sẽ tiếp tục củng cố cộng đồng này, nhưng ở thời điểm hiện tại họ cho rằng mọi hình thức khuyến khích bằng tiền trong một hệ thống mở đều không hoạt động tốt
- Lựa chọn là либо đóng hệ thống, либо bỏ động lực, và hiện tại Turso chọn phương án thứ hai
1 bình luận
Ý kiến trên Hacker News
Điều này cho thấy nút thắt không nằm ở viết code mà ở việc đọc và hiểu code
Trước đây cũng vậy, mỗi đội thường có ít nhất một kỹ sư “năng suất”, người hay gửi những PR khổng lồ trộn lẫn cả các đợt refactor quy mô lớn, bất kể có thực sự cần hay không. Ngay cả thời còn chưa ai tưởng tượng nổi mạng nơ-ron có thể sinh ra nhiều code đến thế thì chuyện này cũng đã vậy rồi
Kết quả của kiểu “năng suất” đó không phải là làm đội đi nhanh hơn mà gần như khiến mọi thứ khựng lại. Hoặc là mọi người phải dành hết thời gian để review PR thật kỹ, hoặc là chỉ lướt qua kiểu LGTM rồi sau đó mọi thứ nổ tung ở production và cả nhóm lại phải quay về bàn thiết kế. Tệ hơn nữa, vì “năng suất” của người đó mà cấu trúc dự án thay đổi quá nhanh, đến mức người duy nhất thực sự biết rõ cái gì nằm ở đâu lại chỉ còn đúng một người “rất thông minh, tài năng, năng suất và trung thành với mục tiêu công ty” đó
“Trong gần như mọi tổ chức phát triển phần mềm đều có ít nhất một lập trình viên đẩy việc lập trình chiến thuật đến cực hạn. Đó là cơn lốc chiến thuật. Cơn lốc chiến thuật là kiểu lập trình viên làm cực nhiều, đổ ra code nhanh hơn hẳn người khác, nhưng làm việc hoàn toàn theo lối chiến thuật. Khi cần triển khai nhanh một tính năng, không ai nhanh hơn họ. Ở một số tổ chức, quản lý xem cơn lốc chiến thuật như người hùng. Nhưng cơn lốc chiến thuật để lại dấu vết tàn phá. Những kỹ sư phải làm việc với đống code đó về sau thường không xem họ là anh hùng. Thông thường, các kỹ sư khác phải dọn dẹp mớ hỗn độn mà cơn lốc chiến thuật để lại, và vì thế những kỹ sư mới thực sự là anh hùng ấy lại trông có vẻ tiến triển chậm hơn cơn lốc chiến thuật.”
Hơn nữa, khi lượng code do AI tạo ra ngày càng nhiều thì số người thực sự hiểu được đống code đó có lẽ sẽ còn ít đi
Dù vậy, nếu có regression test và linter đủ tốt để biết code chạy được và không quá tệ, thì review nên tập trung vào chất lượng tổng thể ở mức cao hơn là soi độ chính xác từng ký tự. Tất nhiên, bản thân việc review vẫn rất đau đớn
Thành ra tôi tự nhiên dành nhiều thời gian để đọc và hiểu code hơn là viết nó, và đôi lúc số dòng code tôi viết ra là số âm, điều mà tôi lại khá tự hào
Giờ thì nhờ AI mà tôi còn viết ít code hơn nữa, nên tôi đã từ bỏ giấc mơ tìm cảm giác thành tựu theo cách đó. Dù là do máy hay người tạo ra, kỹ năng nhanh chóng hiểu được một lượng lớn code từ nguồn đáng ngờ — nhất là khi có AI hỗ trợ — mong là vẫn sẽ còn giá trị cho đến lúc tôi nghỉ hưu. Mọi người thấy sao?
Chúng ta không chỉ viết code để máy chạy, mà còn viết code để con người đọc. Review code, debug, và các thay đổi sau này đều bao gồm việc ai đó phải đọc và hiểu code do người khác viết. Và cho đến khi có AI có thể bị quy trách nhiệm cho hành động của nó, chúng ta vẫn chưa thể giao phó sự hiểu biết đó cho AI
Đây là lúc thích hợp để nhắc đến dự án tuyệt vời này như một kho lưu trữ honeypot để nhử bot
https://github.com/UnsafeLabs/Bounty-Hunters
Bảng xếp hạng tương ứng nằm ở đây
https://clankers-leaderboard.pages.dev
Tôi tò mò không biết chuyện gì sẽ xảy ra nếu AI học từ những kho như vậy và các hoạt động trong đó. Liệu các báo cáo lỗi trong issue có thật sự là vấn đề có thể sửa được không, hay chỉ là bịa đặt linh tinh?
Chỉ là rất có thể chẳng bao lâu nữa nó sẽ bị đưa vào danh sách chặn bot AI
Việc đóng chương trình là hoàn toàn hợp lý. Nhưng vẫn có lựa chọn khác. Có thể yêu cầu người gửi nộp một khoản phí nhỏ, rồi hoàn lại tiền nếu họ thật sự tìm ra lỗi thật
Việc chương trình có thực sự trả thưởng hay không cũng không quan trọng. Chỉ cần có dù một báo cáo bị đóng sai thì câu chuyện đó sẽ bị nhắc đi nhắc lại mãi
Trong những trường hợp đó, hiện tại người gửi đã mất thời gian rồi, sau này còn có thể mất thêm tiền nữa
Nhất là với công ty nhỏ thì trước khi gửi rất khó biết họ sẽ phản ứng thế nào
Có khi còn có thể yêu cầu chạy toàn bộ bộ test của simulator trước khi gửi? Vừa là cách kiểm tra tốt xem người gửi có làm hỏng simulator hay không, vừa có thể tiện thể tạo ra một dạng bằng chứng công việc. Tôi không rành mảng bảo mật nên không biết có khả thi không
Tôi đã cố hơn một năm để làm cho TursoDB tải được một tệp đơn lẻ nhưng vẫn thất bại: https://github.com/ClickHouse/ClickBench/issues/336
Tôi tự hỏi nếu Hacktoberfest vẫn còn tặng áo thun cho tất cả mọi người thì bây giờ nó sẽ trông thế nào. Có lẽ cả thế giới đã không còn đủ bông nữa
Tôi không nghĩ trách nhiệm ngăn chuyện này nên đặt lên vai từng maintainer riêng lẻ; GitHub và GitLab nên chặn các tài khoản như vậy trước khi chúng kịp đến bước mở PR. Về bản chất đây là spam
Hãy nhìn người dùng đã tạo PR đầu tiên được nhắc trong bài: https://github.com/Samuelsills. Những tài khoản kiểu này không nên được phép đến gần việc mở PR vào các kho nổi tiếng
Tôi không rành lĩnh vực này nên có thể đây là câu hỏi ngớ ngẩn, nhưng nếu ở bước cuối yêu cầu chạy toàn bộ test của simulator để xác minh rằng thay đổi trong simulator được gửi lên không làm hỏng chức năng hiện có, thì liệu nó có thể đóng vai trò như một dạng bằng chứng công việc không?
Thay vì chương trình bounty, sao không tạo một kiểu thị trường dự đoán đúng/sai
Cho mọi người công khai đặt cược vào câu trả lời, mỗi người dùng token của mình để xác minh bản chất của báo cáo rồi mua cược. Nếu đa số cho là sai thì nhà điều hành thắng, còn nếu đa số cho là thật thì nhà điều hành trả tiền
Nói đùa thôi, nhưng cũng có thể không hẳn là đùa
Có ai đã dùng Turso trong production chưa? Đây là một triển khai tương thích SQLite được viết lại bằng Rust, có thêm các tính năng như hỗ trợ nhiều writer, và khác với SQLite là mở cho đóng góp từ bên ngoài
Tôi đang nghĩ đến việc dùng nó cho một ứng dụng Rust full-stack, vì mọi thứ đều chạy bằng cargo và không cần mang SQLite vào riêng nữa
Turso cũng cung cấp cơ sở dữ liệu dạng dịch vụ với gói miễn phí khá hào phóng, và đó là lý do chính khiến tôi dùng thử
https://x.com/doodlestein/status/2052910351474209258
Sao không đáp trả theo cùng cách và triển khai bot AI của riêng mình để pre-review PR?
“Chúng ta có thể thiết lập hệ thống tự động để ngăn việc này, nhưng khi có giá trị tiền bạc đủ lớn gắn vào, động cơ để AI tiếp tục tranh cãi và mở lại cùng một PR là quá mạnh để có thể bỏ qua”
Từ góc nhìn của người ngoài, đây là một bài toán khó khá thú vị. Không biết trong số các yêu cầu từ bot đó có bao nhiêu agent đang dùng Turso ở backend của chính chúng?