เราจะยุติโปรแกรมบั๊กบาวน์ตี

 (turso.tech)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Turso ยุติโปรแกรมบั๊กบาวน์ตีที่จ่าย 1,000 ดอลลาร์ สำหรับบั๊กที่พิสูจน์ได้ว่านำไปสู่ข้อมูลเสียหาย หลังดำเนินการมาราว 1 ปี
  • เมื่อมีเงินรางวัลเข้ามา ก็มี PR คุณภาพต่ำที่สร้างโดย AI ไหลบ่าเข้ามาจำนวนมาก ทำให้ผู้ดูแลต้องใช้เวลาหลายวันไปกับการปิด PR เหล่านี้
  • ช่วงแรกมีผู้ได้รับรางวัล 5 คน และผลงานบางส่วนก็นำไปสู่การปรับปรุงซิมูเลเตอร์และการพบบั๊กใน SQLite มากกว่า 10 รายการ
  • Turso ใช้ ระบบรับรอง เพื่อปิด PR ที่น่าสงสัยโดยอัตโนมัติ แต่บอตยังคงเปิด issue ขอรีวิวด้วยคนและส่ง PR ที่คล้ายเดิมกลับมาอีกซ้ำๆ
  • เพื่อคงการเปิดรับการมีส่วนร่วมจากภายนอกไว้ Turso จึงเลือก เอาแรงจูงใจทางการเงินออก แทนการปิดระบบ

เหตุผลที่ Turso หยุดบั๊กบาวน์ตี

  • Turso จ่ายเงิน 1,000 ดอลลาร์สำหรับ บั๊กที่พิสูจน์ได้ว่าสามารถนำไปสู่ข้อมูลเสียหาย มาตลอดเกือบ 1 ปี แต่ตอนนี้ได้ยุติโปรแกรมแล้ว
  • หลังจากมีรางวัลเป็นตัวเงิน รีโพสิตอรีของ Turso ก็เต็มไปด้วย PR คุณภาพต่ำที่สร้างโดย AI และผู้ดูแลต้องใช้เวลาส่วนใหญ่หลายวันไปกับการปิด PR เหล่านี้
  • Turso ต้องการคงความเป็นโครงการที่เปิดรับการมีส่วนร่วม แต่เห็นว่าโครงสร้างที่จ่ายเงินให้กับบั๊กบางประเภททำให้การดูแลการมีส่วนร่วมแบบเปิดแทบเป็นไปไม่ได้
  • การตัดสินใจครั้งนี้ถูกประกาศออกมาพร้อมการตระหนักว่าทุกคนจำเป็นต้องเรียนรู้ร่วมกันว่าจะสร้างธรรมาภิบาลโอเพนซอร์สในยุคใหม่อย่างไร

ที่มาของการเริ่มโปรแกรม

  • Turso กำลัง นำ SQLite มาสร้างใหม่ ซึ่ง SQLite เป็นที่รู้จักว่าเป็นหนึ่งในซอฟต์แวร์ที่เชื่อถือได้มากที่สุดในโลก จึงต้องมีมาตรฐานความน่าเชื่อถือที่สูงตามไปด้วย
  • Turso ใช้ระบบทดสอบหลายแบบเพื่อให้ความน่าเชื่อถือเทียบเท่าหรือเหนือกว่า SQLite
    • ดีเทอร์มินิสติกซิมูเลเตอร์ แบบเนทีฟ
    • ฟัซเซอร์หลายตัว
    • เอนจินทดสอบเชิงเปรียบเทียบแบบ oracle-based ที่เทียบกับ SQLite
    • ซิมูเลเตอร์สำหรับคอนเคอร์เรนซี
    • การรันอย่างกว้างขวางบน Antithesis
  • อย่างไรก็ตาม โครงสร้างพื้นฐานสำหรับการทดสอบก็ยังเป็นซอฟต์แวร์ จึงไม่สมบูรณ์แบบ และสามารถจับบั๊กได้เฉพาะในชุดการผสมที่ตัวสร้างสร้างขึ้นมาจริงเท่านั้น
  • ตัวอย่างเช่น หากฟัซเซอร์ไม่สร้างดัชนี ต่อให้กดดันส่วนอื่นของระบบอย่างหนัก ก็ยังยากที่จะพบบั๊กที่เกี่ยวกับ ดัชนี
  • Turso เคยพบบั๊กที่เกิดขึ้นเฉพาะเมื่อฐานข้อมูลมีขนาด มากกว่า 1GB แต่เพราะมีการฉีดความขัดข้องอย่างหนักในทุกการรัน ฐานข้อมูลจึงโตไม่ถึงขนาดนั้นและทำให้บั๊กหลุดรอดจากซิมูเลเตอร์ไป
  • ข้อดีของการทดสอบอัตโนมัติคือ แม้บั๊กจะหลุดรอดไปครั้งหนึ่ง แต่ถ้าปรับปรุงตัวสร้างการทดสอบได้ ก็สามารถกำจัด บั๊กทั้งหมวดหมู่ นั้นออกไปได้
  • บั๊กบาวน์ตีเป็นกลไกที่ทั้งแสดงความมั่นใจในวิธีการทดสอบของ Turso และใช้ตอบแทนหากมีใครพบพื้นที่ที่ซิมูเลเตอร์ยังครอบคลุมได้ไม่ดี
  • แผนเริ่มต้นคือจ่าย 1,000 ดอลลาร์สำหรับบั๊กข้อมูลเสียหายจนกว่าจะออก Turso 1.0 และหลังจาก 1.0 จึงค่อยๆ ขยายทั้งจำนวนเงินรางวัลและขอบเขตเป้าหมาย

ผลลัพธ์ก่อนที่งานส่งคุณภาพต่ำจาก AI จะเพิ่มขึ้น

  • ในช่วงแรกของโปรแกรม มีผู้ได้รับรางวัลรวม 5 คน และพวกเขามีส่วนช่วยโครงการอย่างมีนัยสำคัญ
  • Alperen เป็นหนึ่งในผู้มีส่วนร่วมหลักของซิมูเลเตอร์ Turso และรู้ว่าตรงไหนยังปรับปรุงได้
  • 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

  • PR ที่อ้างว่าการรัน SQL เป็นช่องโหว่

    • PR #4322 มาในรูปแบบที่เต็มไปด้วยตาราง เครื่องหมายถูกสีเขียว และ em dash พร้อมอ้างว่าพบช่องโหว่ร้ายแรงที่ทำให้สามารถรันคำสั่ง SQL ตามอำเภอใจได้
    • Turso เห็นว่า การที่ฐานข้อมูล SQL อนุญาตให้รันคำสั่ง SQL นั้น ไม่อาจถือเป็นช่องโหว่ได้ในตัวมันเอง

  • PR ที่เข้าใจฟีเจอร์เขียนพร้อมกันของ Turso ผิด

    • PR #6874 เปิดใช้ การเขียนพร้อมกัน ซึ่งเป็นหนึ่งในจุดเด่นของ Turso แล้วแสดงให้เห็นว่า SQLite ไม่สามารถเปิดไฟล์ได้จนกว่าจะเปลี่ยนโหมด journal กลับเป็น WAL เพื่อปิดการเขียนพร้อมกัน
    • นี่คือผลลัพธ์ที่ระบบทำงานตามที่ออกแบบไว้

  • งานส่งที่ยากจะเข้าใจเจตนา

    • งานส่งอีกชิ้น มีเนื้อหาที่ยากจะเข้าใจว่าต้องการทำอะไร
    • ผู้ดูแล Mikael เห็นว่าผู้ส่งน่าจะเห็นประกาศรางวัลแล้วใช้เครื่องมือสร้างด้วย AI เล็งเป้ามาที่ Turso

มาตรการสุดท้าย: ระบบรับรอง

  • Turso ออกแบบและนำ ระบบรับรอง (vouching) มาใช้เป็นความพยายามครั้งสุดท้ายในการจัดระเบียบ
  • ระบบจะปิดงานส่งโดยอัตโนมัติหากสงสัยว่ามาจากบอต และในช่วงหนึ่งก็ได้ผลพอสมควร
  • หลังจากนั้น บอตก็เริ่มเปิด issue เพื่อขอให้มนุษย์ตรวจทาน โดยอ้างเหตุผลว่าทำไม PR จึงถูกปิด
  • หลายครั้งเมื่อปิด PR ไปแล้ว ผู้ใช้คนเดิมหรือผู้ใช้อื่นก็จะเปิด PR ที่เหมือนเดิมหรือคล้ายมากขึ้นมาใหม่แทบจะทันที

ความขัดแย้งระหว่างการมีส่วนร่วมแบบเปิดกับแรงจูงใจทางการเงิน

  • ฝั่งที่สร้างงานส่งคุณภาพต่ำใช้เวลาเพียงประมาณ 1 นาทีในการสร้างงานส่ง แต่ Turso ต้องใช้เวลา หลายชั่วโมง เพื่ออ่าน ทำความเข้าใจ และตอบสนอง
  • งานส่งลักษณะนี้สามารถถูกสร้างขึ้นได้แทบไม่จำกัดความเร็ว
  • แม้จะสามารถสร้างระบบ gatekeeping อัตโนมัติได้ แต่เมื่อมีรางวัลเป็นเงินที่ไม่อาจมองข้าม แรงจูงใจให้ AI โต้เถียงต่อและเปิด PR เดิมซ้ำก็ยิ่งสูงขึ้น
  • Turso ให้ความสำคัญกับชุมชนผู้มีส่วนร่วมโอเพนซอร์สและจะเดินหน้าทำให้แข็งแกร่งขึ้นต่อไป แต่ในตอนนี้เห็นว่า แรงจูงใจทางการเงินทุกรูปแบบในระบบเปิดยังทำงานได้ไม่ดี
  • ตัวเลือกมีอยู่ระหว่างการปิดระบบหรือเอาแรงจูงใจออก และตอนนี้ Turso เลือกอย่างหลัง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • เรื่องคอขวดไม่ได้อยู่ที่ การเขียนโค้ด แต่อยู่ที่การอ่านและทำความเข้าใจโค้ด
    เมื่อก่อนก็มีแทบทุกทีมที่มีวิศวกร “สายผลิต” อยู่สักคน ชอบส่ง PR ก้อนมหึมาที่ปนการรีแฟกเตอร์ครั้งใหญ่เข้าไป ไม่ว่าจะจำเป็นหรือไม่ก็ตาม เรื่องแบบนี้มีมาตั้งแต่ก่อนยุคที่ใครจะจินตนาการได้ว่าโครงข่ายประสาทจะสร้างโค้ดได้มากขนาดนี้
    ผลของ “ประสิทธิภาพ” แบบนั้นไม่ใช่การทำให้ทีมเร็วขึ้น แต่เกือบจะทำให้หยุดนิ่งไปเลย ทีมต้องใช้เวลาหมดไปกับการรีวิว PR อย่างละเอียด หรือไม่ก็ LGTM แบบผ่านๆ แล้วสุดท้ายพังในโปรดักชันจนทุกคนต้องกลับไปที่กระดานออกแบบใหม่ แถมเพราะ “ประสิทธิภาพ” ของคนนั้น โครงสร้างโปรเจ็กต์ก็เปลี่ยนเร็วเกินไป จนคนที่รู้ชัดจริงๆ ว่าอะไรอยู่ตรงไหนเหลือแค่คนเดียว คือคนที่ “ฉลาดมาก มีพรสวรรค์ มีประสิทธิภาพ และภักดีต่อเป้าหมายบริษัท” คนนั้นเอง

    • นี่ทำให้นึกถึงกรณีของ tactical tornado ในหนังสือ A Philosophy of Software Design ของ John Ousterhout มีข้อความตอนหนึ่งว่า
      “แทบทุกองค์กรพัฒนาซอฟต์แวร์จะมีนักพัฒนาอย่างน้อยหนึ่งคนที่ผลักการเขียนโปรแกรมเชิงยุทธวิธีไปจนสุดทาง นั่นคือ tactical tornado คนแบบนี้เป็นโปรแกรมเมอร์สายผลิตที่เขียนโค้ดได้เร็วกว่าคนอื่นมาก แต่ทำงานแบบ tactical ล้วนๆ หากต้องทำฟีเจอร์ด่วนสักอย่าง ไม่มีใครเร็วกว่าเขา ในบางองค์กร ผู้บริหารปฏิบัติต่อ tactical tornado ราวกับเป็นฮีโร่ แต่ tactical tornado จะทิ้งร่องรอยแห่งการทำลายล้างไว้ วิศวกรที่ต้องมาทำงานกับโค้ดนั้นภายหลังมักไม่ได้มองเขาเป็นฮีโร่ ส่วนใหญ่แล้ววิศวกรคนอื่นต้องคอยเก็บกวาดความยุ่งเหยิงที่ tactical tornado ทิ้งไว้ และเพราะเหตุนั้นฮีโร่ตัวจริงเหล่านั้นจึงดูเหมือนทำงานช้ากว่า tactical tornado”
    • เห็นด้วย 100% กับประโยคที่ว่า “คอขวดไม่ได้อยู่ที่การเขียนโค้ด แต่อยู่ที่ การอ่านและทำความเข้าใจโค้ด”
      และยิ่ง AI สร้างโค้ดมากขึ้น ก็จะยิ่งมีคนที่เข้าใจโค้ดนั้นจริงๆ น้อยลง
    • มี PR หนึ่งที่ผมเกือบเป็นคนแบบนั้นเอง โดยอาศัย ไลบรารีและเครื่องมือภายนอก ที่เราใช้อยู่แล้วให้คุ้มขึ้น ผมลบโค้ดในโค้ดเบสไปได้มากกว่า 20% แต่ก็ต้องเปลี่ยนให้แทบทุกจุดไปใช้ฟังก์ชันจากไลบรารีแทนฟังก์ชันที่เราสร้างเอง
      ถึงอย่างนั้น ถ้ามี regression test และ linter ที่ดีพอจนมั่นใจได้ว่าโค้ดยังทำงานและไม่ได้แย่มาก การรีวิวก็ควรดูคุณภาพระดับสูงโดยรวม มากกว่าจะขุดความถูกต้องทีละตัวอักษร แน่นอนว่าการรีวิวก็ยังเจ็บปวดอยู่ดี
    • ตลอดอาชีพผมอยากทำ โปรเจ็กต์แบบ greenfield แต่ในความเป็นจริงกลับทำงานกับโค้ดเบสที่เติบโตแล้วและโปรเจ็กต์ legacy เป็นหลัก
      เลยกลายเป็นว่าใช้เวลาอ่านและทำความเข้าใจโค้ดมากกว่าการเขียนโค้ด และบางครั้งจำนวนบรรทัดโค้ดที่ผมเขียนยังติดลบ ซึ่งผมก็ภูมิใจกับมัน
      ตอนนี้เพราะ AI ทำให้ผมยิ่งเขียนโค้ดน้อยลง ผมก็เลิกหวังจะหาความรู้สึกสำเร็จแบบนั้นไปแล้ว ความสามารถในการเข้าใจโค้ดจำนวนมากจากแหล่งที่น่าสงสัยได้อย่างรวดเร็ว ไม่ว่ามันจะถูกสร้างโดยเครื่องหรือมนุษย์ โดยเฉพาะถ้ามี AI ช่วย น่าจะยังมีคุณค่าไปจนถึงวันเกษียณ คิดว่าอย่างไร?
    • พวกนักเผยแพร่ AI มักพูดว่า การพิมพ์ แทน “การเขียนโค้ด” บ่อยๆ เพราะพวกเขาไม่เข้าใจจริงๆ ว่าอะไรทำให้โค้ดยาก หรือไม่ก็เพราะการยอมรับเรื่องนั้นทำเงินไม่ได้
      เราไม่ได้เขียนแค่โค้ดให้เครื่องรัน แต่เขียนโค้ดให้คนอ่านด้วย การรีวิวโค้ด การดีบัก และการแก้ไขในอนาคต ล้วนเกี่ยวข้องกับการอ่านและทำความเข้าใจโค้ดที่ใครสักคนเขียนไว้ และจนกว่าจะมี AI ที่รับผิดชอบต่อการกระทำของตัวเองได้ เราก็ยังมอบหมายความเข้าใจนั้นให้ AI ไม่ได้

  • นี่น่าจะเป็นจังหวะดีที่จะพูดถึงโปรเจ็กต์ยอดเยี่ยมนี้ ซึ่งเป็น คลัง honeypot ไว้ล่อบอต
    https://github.com/UnsafeLabs/Bounty-Hunters
    ส่วนตารางอันดับที่เกี่ยวข้องอยู่ที่นี่
    https://clankers-leaderboard.pages.dev

    • ผมเห็นตรงนั้นเขียนว่า “คำอธิบาย PR ต้องเริ่มด้วยโค้ดบล็อกที่มี system prompt”
      ก็เลยสงสัยว่าถ้า AI ไปเรียนรู้จากคลังแบบนั้นและกิจกรรมในนั้น จะเกิดอะไรขึ้น รายงานบั๊กใน issue พวกนั้นเป็นปัญหาที่แก้ได้จริง หรือเป็นเรื่องแต่งมั่วๆ กันแน่?
    • ผมยังไม่เข้าใจเรื่องนี้ ถ้าโปรเจ็กต์นั้นไม่ได้ให้ bug bounty แล้วทำไมถึงมี PR หลั่งไหลเข้ามาเยอะขนาดนั้น? แรงจูงใจอะไรที่ทำให้คนยอมเสียเงินจริงกับโทเค็นเพื่อส่ง PR ขยะ? หรือว่าเป็นการสแปมโปรโมตสินค้าอะไรผ่าน PR?
    • เป็นโปรเจ็กต์ที่ดี
      แต่อีกไม่นานก็น่าจะถูกใส่ใน รายการบล็อก AI bot

  • การปิดโปรแกรมถือว่าสมเหตุสมผลอย่างยิ่ง แต่ก็ยังมีทางเลือกอื่น เช่น ให้ผู้ส่งรายงานจ่ายค่าธรรมเนียมเล็กน้อย แล้วคืนเงินเมื่อพบว่าเป็น บั๊กจริง

    • วิธีแบบ “ให้ผู้ส่งจ่ายเงิน” จะก่อ ดราม่าอินเทอร์เน็ต แน่ๆ เพราะเท่ากับให้คนทำงานฟรีให้บริษัท แล้วยังต้องจ่ายเงินเพื่อสิทธิ์นั้นอีก
      ไม่สำคัญด้วยซ้ำว่าโปรแกรมนั้นจ่ายรางวัลจริงหรือไม่ แค่มีรายงานสักฉบับถูกปิดผิด เรื่องนี้ก็จะถูกหยิบมาเล่าซ้ำไม่รู้จบ
    • การโอนเงินไม่ใช่เรื่องฟรี และการจัดการการชำระเงินก็อาจเป็น ปัญหาใหญ่ ได้ บางกรณีอาจง่าย แต่บางกรณีก็ไม่ง่ายเลย
    • น่าเสียดายที่เรื่องนี้ไม่ได้แบ่งเป็นขาวกับดำชัดเจน ใน bug bounty บางแห่ง บริษัทพยายามอย่างหนักที่จะไม่จ่ายรางวัล โดยตีความช่องโหว่ว่าอยู่นอกขอบเขตหรือเป็นพฤติกรรมที่ตั้งใจไว้
      ในกรณีแบบนั้น ตอนนี้ผู้ส่งก็เสียเวลาอยู่แล้ว และต่อไปก็อาจเสียเงินด้วย
      โดยเฉพาะกับบริษัทเล็กๆ ก่อนส่งรายงานไปก็ไม่มีทางรู้ได้เลยว่าบริษัทจะตอบสนองอย่างไร
    • วิธีนี้จะเพิ่ม ภาระงานธุรการ และยิ่งเพิ่มแรงจูงใจให้ผู้ส่งรายงานโต้เถียงไม่รู้จบว่าตัวเองถูก
    • ฟังดูเหมือน bug bounty ควร ขยาย simulator ให้ครอบคลุมประเภทบั๊กที่ผู้ใช้พบ
      อาจจะบังคับให้รันชุดทดสอบของ simulator ทั้งหมดก่อนส่งรายงานได้ไหม? มันน่าจะเป็นการตรวจสอบที่ดีว่าผู้ส่งไม่ได้ทำ simulator พัง และอาจได้ผลพลอยได้เป็นหลักฐานแบบ proof of work ด้วย แต่จะทำได้จริงไหมผมไม่ค่อยรู้ด้านความปลอดภัยเลยตอบไม่ได้

  • ผมพยายามมานานกว่าหนึ่งปีแล้วที่จะทำให้ TursoDB โหลดไฟล์เดี่ยวได้ แต่ไม่สำเร็จ: https://github.com/ClickHouse/ClickBench/issues/336

  • สงสัยว่าถ้า Hacktoberfest ยังแจกเสื้อยืดให้ทุกคนอยู่ ตอนนี้มันจะออกมาหน้าตาแบบไหน คงมี ฝ้าย ไม่พอใช้ทั้งโลก
    ผมคิดว่าภาระในการหยุดเรื่องนี้ไม่ควรตกกับเมนเทนเนอร์แต่ละคน และ GitHub กับ GitLab ควรหยุดบัญชีแบบนี้ตั้งแต่ก่อนจะไปถึงขั้นเปิด PR ได้ โดยแก่นแท้มันคือสแปม
    ลองดูผู้ใช้ที่สร้าง PR แรกที่บทความพูดถึง: https://github.com/Samuelsills บัญชีแบบนี้ไม่ควรได้เข้าใกล้การเปิด PR ในคลังยอดนิยมเลย

    • หมายความว่าบัญชีที่ไม่มีกิจกรรมเลยไม่ควรถูกปล่อยให้อยู่เฉยๆ แบบนั้นหรือ? หรือว่าอาจมีการใช้ อีกบัญชีหนึ่ง ร่วมกัน?

  • ผมไม่ค่อยรู้เรื่องสายนี้ อาจเป็นคำถามโง่ๆ แต่ถ้ากำหนดให้ตอนท้ายต้อง รันการทดสอบ simulator ทั้งหมด เพื่อยืนยันว่าการเปลี่ยนแปลงที่ส่งมาไม่ได้ทำให้ฟีเจอร์เดิมพัง แบบนั้นจะใช้เป็น proof of work ได้ไหม?

  • แทนที่จะเป็นโปรแกรม bounty ถ้าทำเป็น ตลาดพยากรณ์แบบจริง/เท็จ จะเป็นอย่างไร
    ให้คนมาเดิมพันต่อสาธารณะกับคำตอบ โดยแต่ละคนใช้โทเค็นของตัวเองตรวจสอบเนื้อหาของรายงานแล้วซื้อเดิมพัน ถ้าคนส่วนใหญ่มองว่าเป็นเท็จ ผู้ดำเนินการก็ชนะ แต่ถ้าคนส่วนใหญ่มองว่าเป็นเรื่องจริง ผู้ดำเนินการก็จ่ายเงิน
    พูดเล่นนะ แต่ก็อาจไม่เชิงเล่นก็ได้

  • มีใครเคยใช้ Turso ใน โปรดักชัน ไหม? มันเป็น implementation ที่เข้ากันได้กับ SQLite ซึ่งเขียนใหม่ด้วย Rust มีฟีเจอร์เพิ่มอย่างรองรับหลายผู้เขียน และต่างจาก SQLite ตรงที่เปิดรับ contribution จากภายนอกด้วย
    ผมกำลังคิดจะลองใช้กับแอป Rust แบบฟูลสแต็ก เพราะทุกอย่างทำงานผ่าน cargo และไม่ต้องเอา SQLite มาต่างหาก

    • ถ้าจะใส่แทน SQLite ก็ถือว่าโอเค ตอนที่ผมลองเมื่อ 1–2 ปีก่อน เจอปัญหาเกี่ยวกับ libsql บน Windows พอสมควร แต่คิดว่าตอนนี้คงแก้ไปแล้ว
      Turso เองก็มีฐานข้อมูลแบบบริการพร้อม free plan ที่ใจกว้างมาก ซึ่งนั่นเป็นเหตุผลหลักที่ผมเคยใช้มัน
    • มีคนทำ implementation แบบหลายผู้เขียน เป็นโปรเจ็กต์ส่วนตัว รองรับโปรโตคอล sqlite3 และมีการล็อกที่ละเอียดกว่า
      https://x.com/doodlestein/status/2052910351474209258

  • ทำไมไม่สู้กลับด้วยวิธีเดียวกัน ปล่อย AI bot ของตัวเองออกมาเพื่อช่วยคัดกรอง PR ล่วงหน้า?

    • ตามบทความบอกว่า ทำได้อยู่
      “คุณสามารถตั้งระบบอัตโนมัติเพื่อหยุดสิ่งนี้ได้ แต่เมื่อมีมูลค่าทางการเงินที่มองข้ามไม่ได้ AI ก็มีแรงจูงใจสูงมากที่จะเถียงต่อและเปิด PR เดิมซ้ำไปมา”
    • หรืออีกทางก็ทำให้โปรแกรมไม่พังข้อมูลได้ง่ายขนาดนั้น จะได้ไม่ต้องจ่าย 1,000 ดอลลาร์ สำหรับทุก issue ที่มีคนอื่นมาช่วยหาให้

  • จากมุมมองคนนอก นี่เป็น ปัญหายาก ที่น่าสนใจ ในบรรดาคำขอจากบอตพวกนั้น จะมีสักกี่เอเจนต์ที่ใช้ Turso อยู่ในแบ็กเอนด์ของตัวเอง?