バグバウンティプログラムを終了します
(turso.tech)- Tursoは、データ破損を実証したバグに1,000ドルを支払っていたバグバウンティを約1年間運用した後、終了した
- 報奨金が設定されると、AI生成の低品質PRが大量に流入し、メンテナーはそれらを閉じるのに何日も時間を費やした
- 当初は5人に報奨を支払い、一部の貢献はシミュレーターの改善やSQLiteの10件を超えるバグの発見につながった
- Tursoは、疑わしいPRを自動で閉じるvouchingシステムを導入したが、ボットは手動レビューを求めるIssueや類似PRの再投稿を繰り返した
- Tursoは、オープンな貢献を維持するため、システムを閉じるのではなく金銭的インセンティブの撤廃を選んだ
Tursoがバグバウンティを中止した理由
- Tursoはほぼ1年間、データ破損につながることを実証したバグに1,000ドルを支払っていたが、現在はこのプログラムを終了した
- 金銭的報酬が付いてから、TursoのリポジトリにはAI生成の低品質PRが殺到し、メンテナーは何日ものあいだ作業時間の大半をそうしたPRを閉じることに費やさざるを得なかった
- Tursoはオープンなコントリビューションのプロジェクトであり続けたいが、特定の種類のバグに金銭を支払う仕組みは、オープンな貢献の運営をほぼ不可能にすると見ている
- 今回の決定は、新しい時代のオープンソースガバナンスをどう築くかをともに学ぶ必要があるという認識のもとで公開された
プログラムを始めた背景
- Tursoは、世界でもっとも信頼性の高いソフトウェアの1つとして知られるSQLiteを再実装しており、そのぶん高い信頼性基準が求められる
- TursoはSQLite水準の信頼性に追いつく、あるいはそれを上回るために、複数のテスト体制を運用している
- ネイティブの決定的シミュレーター
- 複数のファザー(fuzzer)
- SQLiteと比較するオラクルベースの差分テストエンジン
- 並行性シミュレーター
- Antithesisでの大規模な実行
- ただし、テストインフラも結局はソフトウェアであり完全ではなく、ジェネレーターが実際に生み出す組み合わせの範囲でしかバグを捉えられない
- たとえばファザーがインデックスを作成しなければ、システムのほかの部分に強いストレスをかけても、インデックス関連のバグを見つけるのは難しい
- Tursoは、データベースが1GBを超えたときにのみ現れるバグを見つけたことがあるが、各実行で障害注入を積極的に行っていたため、データベースがそのサイズまで成長できず、シミュレーターをすり抜けていた
- 関連: 互換システムを書く冒険
- 自動テストの利点は、いったん取り逃したバグでも、テストジェネレーターを改善すればバグのカテゴリ全体を除去できる点にある
- バグバウンティは、Tursoのテスト手法への自信を示しつつ、シミュレーターが十分に扱えていない領域を誰かが見つけた場合に報いるための仕組みだった
- 当初の計画では、Turso 1.0のリリース前までデータ破損バグに1,000ドルを支払い、1.0以降は報奨額と対象範囲を段階的に広げていく予定だった
AIによる低品質投稿が増える前の効果
- プログラム初期には合計5人が報奨を受け取り、彼らはプロジェクトに意味のある貢献をした
- AlperenはTursoシミュレーターの主要な貢献者の1人で、改善できる箇所を把握していた
- MikaelはLLMを創造的に使ってシミュレーターが到達できない領域を見つけ、その後Tursoに採用された
- Pavan Nambiはシミュレーターと形式手法を組み合わせ、TursoのバグだけでなくSQLite自体でも10件を超えるバグを発見した
AI生成の投稿が生んだ運用負荷
- Tursoが求めていた投稿基準は、単にバグを指摘することではなく、シミュレーターを拡張してデータ破損バグを実証することだった
- この条件のおかげで、報奨金目当ての悪質なPRは少なく、実際のデータ破損バグも多くはなかった
- その後、LLMにTursoを対象にバグを探して報奨を得るよう指示した投稿が大量に発生した
- LLMはそのような指示を受けると何らかの出力を作るが、その内容が妥当かどうかは別問題だった
代表的な低品質投稿
-
データベースヘッダーを手動で壊したPR
- PR #6257は、データベースヘッダーにゴミのバイト列を手動で注入したうえで、データベースが破損したと主張した
- メンテナーが当然の結果だと指摘した後も、投稿者またはボットはLLM的な長文の反論を続けた
-
ソースコードに直接out-of-boundアクセスを入れた投稿
- 別の投稿では、データベースを壊すためにソースコードへout-of-bound配列アクセスを手動で追加していた
- 関連Issue: tursodatabase/turso#5508
-
SQL実行を脆弱性だと主張したPR
- PR #4322は、表や緑色のチェックマーク、em dashが並ぶ典型的な形式で、任意のSQL文の実行を許す重大な脆弱性を発見したと主張した
- Tursoは、SQLデータベースがSQL文の実行を許すこと自体を脆弱性とは見なしていない
-
Tursoの同時書き込み機能を誤解したPR
- PR #6874は、Tursoの差別化要素の1つである同時書き込みを有効にしたうえで、ジャーナルモードをWALに戻して同時書き込みを無効化するまでSQLiteがファイルを開けないことを示した
- これはシステムが設計どおりに動作した結果だった
-
意図を把握しにくい投稿
- 別の投稿は、何をしようとしているのか把握しにくい内容だった
- メンテナーのMikaelは、投稿者が報奨の告知を見てAI生成ツールをTurso向けに使ったのだと判断した
最後の対応: vouchingシステム
- Tursoは秩序を取り戻す最後の試みとして、vouchingシステムを設計・実装した
- 投稿がボット由来と疑われる場合、自動的に閉じる仕組みで、しばらくはある程度機能した
- その後ボットは、PRが閉じられた理由を問題視して手動レビューを求めるIssueを立て始めた
- PRを閉じると、同じユーザーまたは別ユーザーが、同一または非常によく似たPRをすぐに再投稿することも何度も起きた
オープンな貢献と金銭的インセンティブの衝突
- 低品質な投稿を作る側は、投稿生成に1分ほどしかかけない一方で、Tursoはそれを読み、理解し、対応するのに何時間もかけなければならない
- こうした投稿は、事実上ほぼ無限に近い速度で生成できる
- 自動化されたゲートキーピングシステムを作ることはできるが、無視できない金銭報酬が付くと、AIが議論を続けたり同じPRを再投稿したりするインセンティブが強まる
- Tursoはオープンソースのコントリビューターコミュニティを重視しており、今後も強化していくが、現時点ではオープンなシステムではどの形の金銭的インセンティブもうまく機能しないと見ている
- 選択肢はシステムを閉じるか、インセンティブをなくすかであり、Tursoは現時点では後者を選んだ
1件のコメント
Hacker Newsのコメント
ボトルネックはコードを書くことではなく、コードを読んで理解することにある、という話を示している
昔からどのチームにも1人くらい「生産的な」エンジニアがいて、必要かどうかに関係なく、大規模リファクタリングを混ぜた巨大なPRを出していた。ニューラルネットがこんなに大量のコードを生成できるとは想像もしていなかった時代からそうだった
そうした「生産性」の結果は、チームの速度を上げるどころか、ほとんど止めてしまうことのほうが多かった。PRを細かくレビューするのに時間を使い切るか、雑にLGTMして本番で爆発し、全員がまた設計からやり直す羽目になるかだった。しかもその人の「生産性」のせいでプロジェクト構造があまりに速く変わるので、どこに何があるかを明確に把握しているのが、その「とても賢く、才能があり、生産的で、会社の目標に忠実な」1人だけになる
「ほぼすべてのソフトウェア開発組織には、戦術的プログラミングを極限まで押し進める開発者が少なくとも1人はいる。戦術的トルネードだ。戦術的トルネードは、他の人よりはるかに速くコードを量産する多作なプログラマーだが、完全に戦術的なやり方で働く。素早い機能を1つ実装することにかけては、彼より速い者はいない。組織によっては、マネージャーが戦術的トルネードを英雄のように扱う。しかし戦術的トルネードは破壊の跡を残す。後でそのコードに向き合わなければならないエンジニアは、彼を英雄だとは思わないことが多い。たいていは他のエンジニアが戦術的トルネードの残した混乱を片づけることになり、そのせいで本当の英雄であるそのエンジニアたちのほうが、戦術的トルネードより遅く進んでいるように見えてしまう。」
しかもAI生成コードが増えるほど、実際にそのコードを理解している人はさらに少なくなるだろう
それでも回帰テストとリンターがしっかり整っていて、コードが動き、ひどくないと分かっているなら、レビューは文字どおり1文字ずつの正しさを掘り下げるより、全体としての高レベルな品質を見るものになるべきだ。もちろんレビュー自体は相変わらずつらかった
当然ながら、コードを書くより読む・理解する仕事のほうが多く、時には自分が書いたコード行数がマイナスだったこともあり、それを誇らしく思っていた
今ではAIのおかげでさらにコードを書かなくなり、そういう形で達成感を得る夢は諦めた。機械が作ったにせよ人が作ったにせよ、出所の怪しい大量のコードを素早く理解する能力は、特にAIの助けを借りるなら、引退まで価値を持ち続けてほしいと思う。どうだろう？
私たちは機械が実行するためのコードだけでなく、人が読むためのコードも書いている。コードレビュー、デバッグ、将来の変更はすべて、誰かが書いたコードを読んで理解することを含む。そしてその振る舞いに責任を問えるAIが現れるまでは、その理解をAIに委ねることはできない
ボットを誘い込むハニーポット・リポジトリとして、このすばらしいプロジェクトに触れるには良いタイミングだ
https://github.com/UnsafeLabs/Bounty-Hunters
対応するランキングはこちら
https://clankers-leaderboard.pages.dev
AIがこういうリポジトリやその中の活動を学習したら何が起きるのか気になる。Issueのバグ報告は本当に修正可能な問題なのか、それとも作り話のたわごとなのか？
ただ、そう遠くないうちにAIボットのブロックリストに載る可能性が高い
プログラムを閉じるのは完全に合理的だ。ただ、別の選択肢もある。提出者に少額の手数料を払わせて、実際のバグが見つかった場合はそのお金を返すようにすることだ
実際にプログラムが報酬を払っているかどうかは重要ではない。レポートが1件でも誤ってクローズされれば、その話は延々と蒸し返される
そういう場合、今でも時間を失うのに、今後は金まで失うことになる
特に小さな会社なら、提出前にその会社がどう反応するか分からない
提出前にシミュレータのテストスイート全体の実行を必須にすることもできるのではないか？ 提出者がシミュレータを壊していないか確認する良いチェックになるし、副次的に作業証明の成果物も作れるかもしれない。可能かどうかは、セキュリティ方面に詳しくないので分からない
1年以上、TursoDBに単一ファイルを読み込ませようとしているが、まだ成功していない: https://github.com/ClickHouse/ClickBench/issues/336
Hacktoberfestが今でも全員にTシャツを配っていたら、今どうなっていただろうと思う。おそらく世界中で綿花が足りなくなっていただろう
これを防ぐ責任を個々のメンテナーに負わせるべきではなく、GitHubやGitLabが、こういうアカウントがPRを開ける段階に行く前に止めるべきだと思う。本質的にはスパムだ
記事で最初に言及されているPRを作ったユーザーを見てほしい: https://github.com/Samuelsills. こういうアカウントは有名リポジトリにPRを開ける場所の近くにすら行くべきではない
詳しくない分野なので愚かな質問かもしれないが、提出されたシミュレータ変更が既存機能を壊していないことを確認するため、最後にシミュレータの全テスト実行を要求したら、それは作業証明の役割を果たせるだろうか？
バウンティプログラムの代わりに、一種の真偽予測市場を作ったらどうだろう
公開の場で答えに賭けてもらい、各自が自分のトークンを使ってレポートの実体を検証したうえで賭けを買う方式だ。多数が偽だと判断すれば運営が勝ち、多数が本物だと判断すれば運営が支払う
冗談だが、もしかするとそうでもないかもしれない
Tursoを本番環境で使ったことがある人はいる？ Rustで書き直されたSQLite互換実装で、複数ライター対応のような機能が追加されていて、SQLiteと違って外部コントリビューションにも開かれている
フルスタックRustアプリで使ってみようかと思っている。何もかもcargoで動くし、SQLiteを別途持ってこなくていいからだ
TursoはDBaaSもかなり太っ腹な無料プランで提供していて、それが自分が使ってみた主な理由だった
https://x.com/doodlestein/status/2052910351474209258
同じやり方で対抗して、独自のAIボットを配備してPRを事前審査させることはできないのか？
「これを防ぐための自動化システムを設定することはできるが、無視しがたい金銭的価値が付いていると、AIたちが議論を続け、同じPRを再び開かせるよう仕向けるインセンティブが強すぎる」
部外者の視点からすると興味深い難題だ。あのボットからのリクエストのうち、どれだけ多くのエージェントが自分たちのバックエンドでTursoを使っているのだろう？