Turso chấm dứt chương trình săn lỗi nhận thưởng
(turso.tech)- Turso đã vận hành chương trình săn lỗi nhận thưởng trong khoảng 1 năm, trả 1.000 USD cho các lỗi chứng minh được khả năng gây hỏng dữ liệu, và nay đã kết thúc chương trình
- 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 trình mô phỏng cũng như phát hiện hơn 10 lỗi trong SQLite
- Turso triển khai hệ thống bảo chứng để tự động đóng các PR đáng ngờ, nhưng các bot tiếp tục lặp lại việc mở issue yêu cầu xem xé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 chương trình săn lỗi nhận thưởng
- Turso đã trả 1.000 USD trong gần 1 năm cho các lỗi có thể chứng minh là dẫn đến hỏng dữ liệu, nhưng giờ chương trình này đã kết thúc
- Sau khi có phần thưởng tài chính, kho mã của Turso bị dồn dập bởi các PR chất lượng thấp do AI tạo ra, và các maintainer phải dành phần lớn thời gian trong nhiều ngày chỉ để đóng các PR đó
- Turso vẫn muốn là một dự án mở cho đóng góp cộng đồng, 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 bối cảnh họ nhìn nhận 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ị nguồn mở trong một thời đại 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 một tiêu chuẩn độ tin cậy rất cao
- Turso vận hành nhiều hệ thống kiểm thử để đạt hoặc vượt mức độ tin cậy của SQLite
- Trình mô phỏng quyết định native
- Nhiều fuzzer
- Công cụ kiểm thử vi sai dựa trên oracle để so sánh với SQLite
- Trình mô phỏng đồng thời
- Chạy quy mô lớn trên Antithesis
- Dù 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ỉ bắt được lỗi trong phạm vi các tổ hợp mà bộ sinh thực sự tạo ra
- Ví dụ, nếu fuzzer không tạo chỉ mục, thì dù có gây áp lực mạnh lên các phần khác của hệ thống cũng khó phát hiện lỗi liên quan đến chỉ mục
- Turso từng tìm ra một lỗi chỉ xuất hiện khi cơ sở dữ liệu lớn hơn 1GB, nhưng do mỗi lần chạy đều tiêm lỗi rất mạnh nên cơ sở dữ liệu không thể lớn tới mức đó và lỗi đã thoát khỏi trình mô phỏng
- Nội dung liên quan: Cuộc phiêu lưu khi viết hệ thống tương thích
- Điểm mạnh của kiểm thử tự động là, ngay cả khi một lỗi đã thoát qua một lần, chỉ cần cải thiện bộ sinh kiểm thử là có thể loại bỏ cả một lớp lỗi
- Chương trình săn lỗi nhận thưởng vừa thể hiện sự tự tin của Turso vào phương pháp kiểm thử của mình, vừa là cách thưởng cho ai đó nếu họ tìm được những vùng mà trình mô phỏng 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 đến trước khi Turso 1.0 ra mắt, rồi sau 1.0 sẽ dần mở rộng quy mô thưởng và phạm vi đối tượng
Hiệu quả trước khi làn sóng nộp bài chất lượng thấp do AI xuất hiện
- Ở giai đoạn đầu, tổng cộng 5 người đã nhận thưởng và họ có đóng góp thực sự có ý nghĩa cho dự án
- Alperen là một trong những người đóng góp cốt lõi cho trình mô phỏng của Turso và hiểu rõ những điểm còn có thể cải thiện
- Mikael đã dùng LLM một cách sáng tạo để tìm ra những vùng mà trình mô phỏng không chạm tới, và sau đó được Turso tuyển dụng
- Pavan Nambi kết hợp trình mô phỏng với các kỹ thuật hình thức để phát hiện 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 các bài nộp do AI tạo ra
- Tiêu chuẩn nộp bài mà Turso mong muốn không chỉ là chỉ ra lỗi đơn thuần, mà là mở rộng trình mô phỏng để chứng minh lỗi hỏng dữ liệu
- Nhờ điều kiện đó, các PR xấu chỉ nhằm lấy thưởng từng khá hiếm, và số lỗi hỏng dữ liệu thực sự cũng không nhiều
- Về sau, xuất hiện hàng loạt bài nộp được tạo bằng cách yêu cầu LLM tìm lỗi trong Turso để nhậ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
Những bài nộp chất lượng thấp tiêu biểu
-
PR tự tay làm hỏng header cơ sở dữ liệu
- PR #6257 tuyên bố rằng cơ sở dữ liệu đã bị hỏng sau khi tự chèn các byte rác vào header cơ sở dữ liệu
- Ngay cả sau khi maintainer chỉ ra đây là kết quả hiển nhiên, người nộp hoặc bot vẫn tiếp tục phản bác dài dòng theo kiểu LLM
-
Bài nộp tự chèn truy cập vượt biên vào mã nguồn
- Một bài nộp khác đã tự thêm truy cập mảng vượt biên 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ó dạng đầy bảng biểu, dấu tick xanh và em dash, đồng thời khẳng định đã tìm ra 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 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 đến khi chuyển journal mode trở lại WAL để tắt ghi đồng thời
- Đây là kết quả đúng như cách hệ thống được thiết kế
-
Những bài nộp khó hiểu về ý định
- Một bài nộp khác có nội dung rất khó xác định là đang cố làm gì
- Maintainer Mikael cho rằng người nộp đã thấy thông báo tiền thưởng rồi dùng công cụ tạo nội dung bằng AI nhắm thẳng 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 làm là tự động đóng các bài nộp bị nghi là đến từ bot, và trong một thời gian nó có tác dụng nhất định
- Sau đó, các bot bắt đầu mở issue yêu cầu xem xét thủ công bằng cách chất vấn lý do PR bị đóng
- Cũng nhiều lần xảy ra việc sau khi một PR bị đóng, cùng người dùng hoặc người dùng khác lập tức mở lại một PR giống hệt hoặc rất tương tự
Xung đột giữa đóng góp mở và động lực tài chính
- Phía tạo ra các bài nộp chất lượng thấp chỉ cần 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 nộp như vậ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 hệ thống kiểm soát tự động, nhưng khi gắn với phần thưởng tài chính đủ đáng kể, AI sẽ luôn có động lực tiếp tục tranh cãi và mở lại cùng một PR
- 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 đó, nhưng ở thời điểm hiện tại họ cho rằng bất kỳ hình thức động lực tài chính nào trong một hệ thống mở đều không vận hành 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?