ทางเลือกด้านวิศวกรรมของ Bitcoin แสดงให้เห็นว่าแรงจูงใจ โมเดลภัยคุกคาม และความเรียบง่ายช่วยให้ระบบทำงานได้แม้จะมีผู้ประสงค์ร้ายพยายามทำลายมัน

ออกแบบให้รับคนแปลกหน้า ไม่ใช่เพื่อนสมมติ สมมติว่าใครบางคนจะพยายามทำกำไรจากการทำลายกฎของคุณ (สแปม, ฉ้อโกง, สมรู้ร่วมคิด, ปฏิเสธการให้บริการ) แล้วทำให้เส้นทางที่ซื่อสัตย์เป็นวิธีที่ถูกและง่ายที่สุดในการได้สิ่งที่ต้องการ\n\nคำกระตุ้นที่มีประโยชน์คือ: “ถ้าฉันจ่ายใครสักคนให้ละเมิดฟีเจอร์นี้ เขาจะทำอะไรเป็นอย่างแรก?”
โมเดลภัยคุกคามคือรายการสั้นๆ ของ:\n\n- สินทรัพย์: สิ่งที่ห้ามโดนขโมย ปลอมแปลง หรือลบเปลี่ยน (ยอดเงิน, บันทึกตรวจสอบ, การจ่ายเงิน)\n- ผู้โจมตี: ใครอาจโจมตีได้ (บอต, ผู้มีสิทธิภายใน, คู่แข่ง) และสิ่งที่พวกเขาได้\n- สมมติฐาน: สิ่งที่คุณเชื่อถือได้ (เซิร์ฟเวอร์, ผู้ดูแล, ตราทางเวลา, การยืนยันตัวตน)\n- การโจมตีชั้นนำ: วิธีที่ถูกที่สุดในการทำให้ระบบของคุณพัง\n\nทำให้มันเล็กและจับต้องได้ เพื่อที่คุณจะได้ใช้งานมันในระหว่างการพัฒนา
ในระบบเปิด ตัวตนมีราคาถูก: คนเดียวอาจสร้างบัญชีเป็นพันได้ ถ้าการมีอิทธิพลขึ้นกับ “จำนวนผู้ใช้” ผู้โจมตีชนะได้ด้วยการปลอมผู้ใช้\n\nBitcoin ผูกอิทธิพลกับ proof-of-work ซึ่งมีต้นทุนโลกจริง บทเรียนไม่ใช่ "ต้องใช้การขุด" แต่คือ: ให้พลังขึ้นกับสิ่งที่ปลอมได้ยากหรือมีต้นทุนจริง (ค่าใช้จ่าย, การวางเดิมพัน, เวลา, ความพยายามที่ตรวจสอบได้, ทรัพยากรมีจำกัด)
คนขุดได้รับรางวัลเมื่อพวกเขาผลิตบล็อกที่โหนดอื่นยอมรับ หากพวกเขาทำผิดกฎ โหนดจะปฏิเสธบล็อกและคนขุดจะไม่ได้อะไร\n\nนั่นทำให้แรงจูงใจตรงกัน: ทางง่ายที่สุดในการรับรายได้สม่ำเสมอคือการทำตามกฎฉันทามติ ไม่ใช่พยายามโต้แย้งหรือเขียนประวัติใหม่
ผู้โจมตีที่มี 51% มักจะสามารถ:\n\n- เรียงลำดับประวัติระยะสั้นใหม่ และพยายาม double spend\n- เซ็นเซอร์ บางรายการด้วยการไม่ใส่ลงในบล็อก\n- ทำลายความเชื่อมั่น โดยทำให้การยืนยันดูไม่น่าเชื่อถือในช่วงโจมตี\n\nแต่พวกเขายังไม่สามารถลงชื่อรายการแทนเจ้าของคีย์ส่วนตัวหรือสร้างเหรียญจากอากาศได้ ข้อสรุปคือ: ระบุชัดเจนว่าผู้โจมตีสามารถเปลี่ยนอะไรได้บ้าง แล้วออกแบบรอบขอบเขตเหล่านั้น
ไม่ใช่การโจมตีทั้งหมดจะ "ทำลายกฎ" บางอย่างเกี่ยวกับการควบคุมสิ่งที่เหยื่อ เห็น หรือ เข้าถึงได้\n\nตัวอย่างที่พบบ่อย:\n\n- Eclipse attacks: แยกโหนดให้ได้ยินแค่ผู้โจมตี\n- การแบ่งเครือข่าย: แยกกลุ่มให้มีความเห็นต่างกันเกี่ยวกับสถานะล่าสุด\n- ปฏิเสธการให้บริการ: ทำให้แบนด์วิดท์ ซีพียู หรือช่องเชื่อมต่อหมด\n\nสำหรับทีมผลิตภัณฑ์ อนาล็อกคือ การจำกัดอัตรา การ throttle การใช้งาน และการออกแบบให้รองรับการล้มครึ่งหนึ่งและ retry
ทุกฟีเจอร์เพิ่มกรณีขอบ และกรณีขอบคือที่ซ่อนของการโจมตี (การเล่นซ้ำ, เงื่อนไขแข่งขัน, การเปลี่ยนสถานะแปลกๆ)\n\nกฎเรียบง่าย:\n\n- ตรวจเช็คได้ง่ายเมื่อมีแรงกดดัน\n- ทดสอบได้ง่ายกับสถานการณ์เป็นผู้โจมตี\n- ยากต่อการ "เล่นงาน" ด้วยการจัดเวลาอันชาญฉลาดหรือข้อยกเว้น\n\nถ้าต้องเพิ่มความซับซ้อน ให้จำกัดมันด้วยขอบเขตและความคงตัวที่ชัดเจน
เริ่มด้วยสามแนวทาง:\n\n- เพิ่มต้นทุนการละเมิด: มัดจำ, ค่าธรรมเนียม, หน่วงเวลา, การยืนยันสำหรับการกระทำความเสี่ยงสูง\n- จำกัดการสัมผัส: เพดานต่อบัญชีและต่ออุปกรณ์, การปลดล็อกแบบหน่วงสำหรับรางวัล\n- วางมาตรการกู้คืน: การบันทึก การแจ้งเตือน และกระบวนการย้อนกลับ/แช่แข็งที่ชัดเจน\n\nตัวอย่าง: เครดิตการแนะนำควรถูกปลดล็อกหลังจากกิจกรรมจริง ไม่ใช่แค่การลงชื่อเข้าใช้ และรูปแบบต้องสงสัยควรหยุดรางวัลโดยอัตโนมัติ
ข้อผิดพลาดที่พบบ่อยได้แก่:\n\n- ก็อปปี้โทเค็นโดยไม่ตั้งงบความปลอดภัย: ให้มีรางวัล แต่การโจมตียังถูก\n- พึ่งพา "ชุมชน" แทนแรงจูงใจ: คนโกงหาผลประโยชน์\n- ข้อยกเว้นและคำสั่งผู้ดูแลมากเกินไป: ผู้โจมตีมองหาช่องพิเศษ\n\nกฎเกณฑ์ที่เปลี่ยนบ่อยก็เป็นกับดัก: ทุกการย้ายมีหน้าต่างให้โจมตี
ใช้เพื่อบีบให้มีวินัย ไม่ใช่เพิ่มความซับซ้อน โพรเซสที่ใช้งานได้จริงคือ:\n\n- ใน โหมดวางแผน เขียนสินทรัพย์ ผู้โจมตี และกรณีการละเมิดหลักสำหรับแต่ละฟลูว์ผู้ใช้\n- ใส่ การจำกัดอัตรา, หน่วงเวลา, และเพดาน ให้กับฟีเจอร์ที่สร้างผลกำไรโดยตรง (เครดิต, การจ่ายเงิน, การแนะนำ)\n- ใช้ สแนปชอตและการย้อนกลับ เพื่อกู้คืนเร็วเมื่อการโจมตีสอนบทเรียนใหม่\n- รักษากฎให้นิ่งและตรวจสอบได้; เปลี่ยนอย่างรอบคอบ ไม่ใช่รายสัปดาห์\n\nเป้าหมายคือผลิตภัณฑ์ที่คาดการณ์ได้แม้จะมีคนพยายามทำลายมัน