คำติชมของ EIP-3074 และการเปลี่ยนอย่างง่าย

สำหรับนักพัฒนา กลไก AUTH/AUTHCALL นั้นน่าสนใจมาก ช่วยให้สามารถสร้างผู้เรียกเพื่อใช้กลยุทธ์แบทช์ที่แตกต่างกัน (เช่น รองรับหลาย nonce เพื่อการทำงานแบบคู่ขนานที่ดีขึ้น) แบบจำลองการแยกก๊าซ วิธีแยกบัญชีที่ซับซ้อน เป็นต้น

ความยืดหยุ่นนี้เกิดจากอิสระอันยิ่งใหญ่ที่กลไกนี้มอบให้กับนักพัฒนา กลไก AUTH/AUTHCALL ไม่ต้องการให้นักพัฒนาทำตามรูปแบบเฉพาะ แต่กำหนดให้ผู้ใช้ลงนามในค่าแฮชของคอมมิต (ผู้เรียกจะแยกวิเคราะห์เนื้อหาของคอมมิต) ทำให้นักพัฒนาสามารถตั้งค่าข้อจำกัดของตนเองตามคอมมิต

อย่างไรก็ตาม ความยืดหยุ่นนี้มาพร้อมกับค่าใช้จ่ายด้านความปลอดภัย ในบทความนี้ ฉันต้องการแนะนำทางเลือกที่ง่ายกว่า วิธีนี้มีข้อดีส่วนใหญ่ของกลไก AUTH/AUTHCALL แต่ความเสี่ยงต่ำกว่าวิธีหลังมาก

เหตุใดการลงนามใน AUTH จึงมีความเสี่ยงมากกว่าการลงนามธุรกรรมที่เกี่ยวข้องกับสัญญาที่มีช่องโหว่/เป็นอันตราย

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

ในทางตรงกันข้าม EIP 3074 ไม่เพียงกำหนดให้ผู้ใช้เซ็น "เครื่องหมายถูก" เท่านั้น แต่ยังถือว่าผู้โทรมีความซื่อสัตย์และไม่มีช่องโหว่ ผู้โทรที่เป็นอันตราย/มีช่องโหว่สามารถดำเนินการใดๆ ในนามของผู้ใช้ - เข้าถึงเนื้อหาที่ผู้ใช้ถืออยู่ ลงคะแนนเสียงในนามของผู้ใช้ สัญญาควบคุมที่เป็นของผู้ใช้ ฯลฯ

แย่กว่านั้น ผู้โทรสามารถทำสิ่งชั่วร้ายได้ตลอดเวลา เนื่องจากการดำเนินการแบบ nonce อยู่ภายใต้การควบคุมของผู้โทร การใช้งานลอจิกแบบไม่มีช่องโหว่/ที่เป็นอันตรายอาจทำให้ผู้ใช้ทำธุรกรรมในอดีตซ้ำได้ หากลอจิกของส่วนอื่นๆ ของการยืนยันคอมมิทมีช่องโหว่ ผู้เรียกใช้สามารถใช้ลอจิกที่ไม่เกี่ยวข้องนี้เพื่อดำเนินการใดๆ ในนามของผู้ใช้ แม้ว่าจะพบช่องโหว่ ผู้ใช้ก็ไม่สามารถถอนเช็คเปล่าได้ บัญชีภายนอก (EOA) นี้ถูกบุกรุกอย่างถาวร

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

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

ชื่อเรื่องรอง

ตัวอย่างการจี้การกำกับดูแล

• EveSwap การแลกเปลี่ยนแบบกระจายอำนาจที่เป็นอันตรายได้เขียนโปรแกรมผู้โทรสำหรับผู้ใช้ โปรแกรมผู้โทรนี้ให้เงินทุนแก่ผู้ใช้โดยการทิ้งโทเค็น EVE ลงในอากาศ และแบทช์การอนุมัติของผู้ใช้และธุรกรรมการโอน

• โปรแกรมผู้โทรของ EveSwap ดูเหมือนจะไม่เป็นอันตรายและจะไม่ขโมยโทเค็นของผู้ใช้ เพราะจะถูกเปิดเผยในทันที

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

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

• เมื่อจำนวนที่อนุญาตถึงเกณฑ์ที่กำหนด EveSwap จะจี้ AliceSwap ผ่านข้อเสนอการกำกับดูแล

• ชื่อเรื่องรอง

ตัวอย่างการเล่นซ้ำข้ามสายโซ่

EIP 3074 แนะนำอย่างสมเหตุสมผลว่าการคอมมิตควรมี chainids อย่างไรก็ตาม สิ่งนี้บังคับใช้โดยผู้โทร ไม่ใช่โปรโตคอล ผู้โทรที่มีที่อยู่เดียวกันในเครือข่ายอื่นอาจข้ามการตรวจสอบนี้ (หรือตรวจสอบเรื่องนั้น)

• EveSwap ทำงานบน BobSpongeChain ที่เข้ากันได้กับ EVM ซึ่งรองรับ EIP 3074 EveSwap ปรับใช้ผู้โทรที่ซื่อสัตย์บน BobSpongeChain

• ผู้ใช้ใช้ผู้โทรนี้เพื่อทำธุรกรรมบน BobSpongeChain จากนั้นใช้บริดจ์เพื่อโอนสินทรัพย์ไปยัง Ethereum

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

• ด้วยวิธีนี้ EveSwap สามารถขโมยบัญชีภายนอกของผู้ใช้บน Ethereum และนำทรัพย์สินของพวกเขาไป

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

  ชื่อเรื่องรอง

เราสามารถทำอะไรได้อีก?

ข้อเสนอของฉันคือการใช้กลไกที่ชัดเจนยิ่งขึ้นซึ่งบังคับใช้ความหมายของการกระทำที่ระดับโปรโตคอล โครงสร้างการคอมมิตจะถูกพิมพ์ (ตามที่อธิบายไว้ใน EIP 712) และกระเป๋าเงินจะแสดงการคอมมิตในรูปแบบที่ผู้ใช้อ่านได้ ผู้ใช้สามารถทราบได้อย่างแน่ชัดว่าธุรกรรมมีลักษณะอย่างไร และมั่นใจได้ว่าธุรกรรมนี้จะไม่ถูกเล่นซ้ำในเครือข่ายใด ๆ โดยไม่ต้องพึ่งพาลักษณะและความสามารถของผู้พัฒนาโปรแกรมการโทร

การดำเนินการที่เป็นไปได้:

AUTH จะแทนที่แฮชคอมมิตด้วยโครงสร้างแบบพิมพ์ที่มีรายการการโทรที่ได้รับอนุญาต การโทรแต่ละครั้งจะระบุ {nonce,to,gas,calldata,value,chainid} ลายเซ็นจะได้รับการยืนยันและรายการการโทรที่ได้รับอนุญาตทั้งหมดจะถูกบันทึกเป็น Authorized_transactions แทนตัวแปรที่อยู่ที่ได้รับอนุญาต

AUTHCALL จะได้รับดัชนีพารามิเตอร์ใหม่ที่ชี้ไปยังที่อยู่ในรายการที่สร้างโดย AUTH ล่าสุด

ไม่มีที่อยู่ของผู้ใช้จะเพิ่มขึ้นด้วย AUTHCALL nonce ไม่ได้ถูกจัดเก็บโดยผู้โทร แต่เป็นบัญชีจริง nonce

กำไร:

• ผู้ใช้สามารถเข้าใจสถานการณ์ได้อย่างชัดเจน

• รับประกันความปลอดภัยโดยโปรโตคอล

• แบทช์และนามธรรมของบัญชียังคงรองรับอยู่

• ข้อเสีย:

• การใช้งาน nonce ไม่สนับสนุนความเท่าเทียม

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

• การใช้งานที่แตกต่างกันอาจสนับสนุนรูปแบบ nonce ที่แตกต่างกัน อย่างไรก็ตาม ไม่ว่าเราจะใช้กลไกใดก็ตาม กลไกนั้นจะต้องดำเนินการโดยโปรโตคอล ไม่ใช่ผู้เรียก

  ชื่อเรื่องรอง

ทางเลือก: หลีกเลี่ยงการฮาร์ดฟอร์กโดยสิ้นเชิง

นอกจากนี้ยังมีตัวเลือกในการหลีกเลี่ยงกลไกการตรวจสอบสิทธิ์ทั้งหมด และแก้ปัญหาการแยกบัญชีและการแบทช์ด้วยกลุ่มธุรกรรมทางเลือกตามที่แนะนำโดย vbuterin

กำไร:

• ไม่ต้องใช้ฮาร์ดฟอร์ก รองรับโดยสัญญาอัจฉริยะและโหนดที่รับรู้สัญญาอัจฉริยะเหล่านั้น

• สามารถใช้กับการนำไปใช้งานที่สนับสนุน EIP 3074 โดยไม่ทำให้เกิดความเสี่ยงเพิ่มเติม

• ข้อเสีย:

• ไม่รองรับย้อนหลังกับบัญชีภายนอกที่มีอยู่ ผู้ใช้จำเป็นต้องปรับใช้กระเป๋าเงินสัญญาและโอนสินทรัพย์ไปยังกระเป๋าเงิน

• ลิงค์ต้นฉบับ:

ลิงค์ต้นฉบับ:

https://blog.mycrypto.com/eip-3074/

แปลและพิสูจน์อักษร: Min Min & A Jian

แปลและพิสูจน์อักษร: Min Min & A Jian