วาทิลิก บูเทอริน กล่าวว่าการจำลองธุรกรรมสามารถปิดช่องว่างระหว่างเจตนาของผู้ใช้และผลลัพธ์บนเชน ซึ่งจะเปลี่ยนแปลงความปลอดภัยของคริปโตตั้งแต่รากฐาน
ผู้ร่วมก่อตั้ง Ethereum วาทิลิก บูเทอริน ได้เสนอแนวคิดใหม่เกี่ยวกับความปลอดภัยในคริปโต ซึ่งไม่ได้เริ่มจากโค้ด แต่เริ่มจากเจตนา
ในโพสต์บน X วาทิลิก บูเทอริน โต้แย้งว่าความปลอดภัยและประสบการณ์ของผู้ใช้ไม่ใช่เรื่องแยกจากกันเลย ทั้งสองเรื่องเกี่ยวกับการลดช่องว่างระหว่างสิ่งที่ผู้ใช้ต้องการจริงๆ กับสิ่งที่ระบบทำจริงๆ ความแตกต่างคือ ความปลอดภัยจะรับมือกับเวอร์ชันที่แย่ที่สุดของช่องว่างนั้น ซึ่งพฤติกรรมของฝ่ายตรงข้ามทำให้ต้นทุนของความเบี่ยงเบนสูงมาก
ข้อโต้แย้งนี้เจาะลึกลงไปในสิ่งที่นักพัฒนาคริปโตส่วนใหญ่มักมองข้าม
ทำไม “ความปลอดภัยสมบูรณ์แบบ” จึงไม่เคยเป็นจริง
บูเทอรินกล่าวบน X ว่า ความปลอดภัยสมบูรณ์แบบเป็นไปไม่ได้ ไม่ใช่เพราะเครื่องจักรล้มเหลว ไม่ใช่เพราะวิศวกรทำผิด แต่เป็นเพราะเจตนาของมนุษย์ซับซ้อนเกินกว่าจะเข้ารหัสได้อย่างสมบูรณ์
เขายกตัวอย่างง่ายๆ ผู้ใช้ต้องการส่ง 1 ETH ไปยังบ็อบ ฟังดูชัดเจน แต่ “บ็อบ” ไม่สามารถนิยามทางคณิตศาสตร์ได้ คีย์สาธารณะอาจผิดพลาด เถรษฐีอาจแตกกิ่ง “ETH” ก็เป็นเรื่องเชิงความหมาย ช่องว่างระหว่างภาพในโลกจริงของผู้ใช้กับการแทนค่าทางคณิตศาสตร์ของระบบคือที่อยู่ของความเสี่ยง
มันยิ่งซับซ้อนขึ้นเมื่อเป้าหมายด้านความเป็นส่วนตัว การเข้ารหัสข้อความดูเหมือนเพียงพอ แต่ metadata รูปแบบเวลา และกราฟการสื่อสารสามารถรั่วไหลข้อมูลจำนวนมาก อะไรคือสิ่งที่ถือเป็นการเปิดเผยข้อมูลที่ไม่สำคัญ versus การเปิดเผยข้อมูลที่ร้ายแรง? ไม่มีสูตรใดตอบได้อย่างชัดเจน
หลักการสำรองข้อมูลที่บูเทอรินสนับสนุน
การแก้ปัญหาที่บูเทอรินชี้ให้เห็นไม่ใช่การเพิ่มกลอนล็อคที่แข็งแรงขึ้นเพียงอันเดียว แต่เป็นการมีข้อกำหนดซ้อนทับกัน ระบบจะทำงานก็ต่อเมื่อคำอธิบายเจตนาในหลายมิติสอดคล้องกัน
เขายกตัวอย่างหลายกรณีของรูปแบบนี้ที่ใช้งานจริงแล้ว ระบบประเภทนี้ในโปรแกรมมิ่งทำให้นักพัฒนาต้องเขียนทั้งสิ่งที่โค้ดทำและรูปร่างของข้อมูลแต่ละโครงสร้าง หากสองคำอธิบายไม่ตรงกัน ก็ไม่คอมไพล์ การตรวจสอบอย่างเป็นทางการก็ทำสิ่งที่คล้ายกัน วอลเล็ต multisig ต้องการกุญแจหลายอันเห็นด้วยก่อนที่จะโอนเงิน ข้อเตือนเรื่องขีดจำกัดการใช้จ่ายจะทำงานเมื่อสิ่งใดสิ่งหนึ่งดูผิดปกติ
การจำลองธุรกรรมก็ใช้ตรรกะเดียวกัน ตามคำกล่าวของวาทิลิก บูเทอรินบน X ผู้ใช้ระบุการดำเนินการก่อน แล้วดูตัวอย่างจำลองว่าเกิดอะไรขึ้นบนเชน การคลิกยืนยันหรือยกเลิกการจำลองนั้นกลายเป็นข้อกำหนดอีกข้อหนึ่ง ทั้งสองต้องชี้ไปในทิศทางเดียวกัน
การเพิ่มการยืนยันในธุรกรรมทำให้เรื่องนี้ลึกซึ้งขึ้นไปอีก ธุรกรรมเองเข้ารหัสทั้งการดำเนินการและผลลัพธ์ที่คาดหวัง หากไม่ตรงกันตอนดำเนินการ ธุรกรรมจะล้มเหลว
คุณอาจสนใจ: npm Worm ขโมยกุญแจคริปโต เป้าหมาย 19 แพ็กเกจ
ที่มาของ LLMs ในภาพรวม
แต่บูเทอรินไม่ได้หยุดอยู่แค่เครื่องมือแบบเดิม เขาวาดเส้นตรงจากกรอบแนวคิดนี้ไปยังวิธีที่โมเดลภาษา AI ควรและไม่ควรใช้ในความปลอดภัยของคริปโต
เขากล่าวในโพสต์บน X ว่า LLM แบบทั่วไปทำหน้าที่เหมือนเงาของสามัญสำนึกของมนุษย์ โมเดลที่ปรับแต่งให้เหมาะสมกับพฤติกรรมของผู้ใช้เฉพาะบุคคลจะประมาณความรู้สึกของผู้ใช้นั้นว่าอะไรเป็นปกติหรือผิดปกติ ซึ่งเป็นมุมมองอีกด้านหนึ่งที่สามารถประมาณเจตนาได้ แตกต่างจากโค้ดหรือลายเซ็นเข้ารหัส ซึ่งเป็นจุดสำคัญ การมีข้อกำหนดซ้อนทับกันทำงานได้ดีที่สุดเมื่อข้อกำหนดมาจากทิศทางที่แตกต่างกันอย่างสิ้นเชิง
อย่างไรก็ตาม เขาชัดเจนเกี่ยวกับขีดจำกัดของมัน LLM ควรไม่ใช่สิ่งเดียวที่ตัดสินใจว่าธุรกรรมสะท้อนเจตนาของผู้ใช้หรือไม่ เพราะจะทำให้การซ้อนทับกันของความปลอดภัยทั้งหมดล้มเหลว
อ่านเพิ่มเติม: แผนชั้น Cypherpunk ของวาทิลิก อาจเปลี่ยนแปลง Ethereum ตลอดกาล
ความปลอดภัยไม่ได้หมายถึงการคลิกมากขึ้น
ประเด็นหนึ่งที่บูเทอรินเน้นไว้เป็นพิเศษคือ ความปลอดภัยที่ดีไม่ได้หมายความว่าผู้ใช้ต้องยืนยันทุกอย่างบ่อยขึ้น ซึ่งจะเป็นการแลกเปลี่ยนปัญหาอีกแบบหนึ่ง
เป้าหมายที่แท้จริงตามที่เขาอธิบายบน X คือ การทำให้การดำเนินการที่มีความเสี่ยงต่ำเป็นเรื่องง่ายหรือเป็นอัตโนมัติ ในขณะที่การดำเนินการที่อันตรายจริงๆ ยากขึ้น ความสมดุลนี้คือความท้าทายในการออกแบบที่แท้จริง การสร้างแรงเสียดทานในจุดที่ผิดไม่ช่วยปกป้องผู้ใช้ แต่กลับฝึกให้พวกเขาคลิกผ่านคำเตือนโดยไม่อ่าน
ข้อสังเกตนี้มีผลโดยตรงต่อวิธีการสร้างกระเป๋า Ethereum รวมถึงทุกชั้นของสแต็ก ตั้งแต่ระบบปฏิบัติการ ไปจนถึงการตรวจสอบสมาร์ทคอนแทรกต์ ไปจนถึงฮาร์ดแวร์ หลักการเดียวกันนี้ใช้ได้กับทุกส่วน
อ่านเพิ่มเติม: Bitcoin ETF ดึงดูดเงิน 88 ล้านดอลลาร์ ขณะที่ Ethereum Flow เริ่มชะลอตัวใกล้ศูนย์
กรอบแนวคิดของบูเทอรินไม่ได้สัญญาว่าจะแก้ปัญหาได้สมบูรณ์ แต่เสนอแนวทางที่ดีกว่าในการคิดเกี่ยวกับปัญหาที่ไม่สามารถแก้ได้ ข้อกำหนดเดียวของเจตนาของผู้ใช้จะไม่มีวันสมบูรณ์แบบ คำถามคือ คุณสามารถตรวจสอบมันจากมุมมองที่แตกต่างกันได้กี่ด้าน ก่อนที่ระบบจะดำเนินการ
