สำรวจมาตรฐานทั่วไปสำหรับธุรกรรมเมตาของ Ethereum

หมายเหตุบรรณาธิการ: บทความนี้มาจาก:ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก:

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

บทความนี้เป็นการตอบสนองของ Bloxis ต่อการแข่งขันของ Metamask เพื่อสรุป metatransactions ใน Gitcoin ในขณะที่เราวางแผนที่จะรวมฟังก์ชันนี้เข้ากับผลิตภัณฑ์ที่กำลังจะมาถึง เราได้ใช้เวลาและความพยายามอย่างมากในด้านนี้ ด้วยเหตุนี้ เราจึงต้องการที่จะมีส่วนร่วมในการอภิปรายในด้านนี้ หากคุณมีข้อโต้แย้งใด ๆ กับความคิดเห็นของฉัน โปรดชี้ให้เห็น และเรายินดีที่จะพูดคุยกับคุณ

การแนะนำ

- ที่มา: Gitcoin -

การแนะนำ

ตราบใดที่คุณยินดีจ่ายเงิน คุณสามารถดำเนินการใดๆ ก็ได้ (ไม่เกินขีดจำกัดของแก๊ส) ในธุรกรรม Ethereum บนเครือข่ายบล็อกเชนไร้พรมแดนที่กระจายอำนาจเกือบทั้งหมด ฟังดูดีมากใช่ไหม นั่นคือความจริง แต่! ปัญหาคือต้องใช้ Gas ในการทำธุรกรรม และ Gas จ่ายด้วย Ethereum แต่ใครมี Ethereum สำหรับผู้ใช้ใหม่ (อะไรนะ คุณบอกว่ามีไซเบอร์พังก์ ปาร์ตี้สะสมเหรียญ และองค์กร MLM เหรอ เอาเลย พวกนั้นไม่ใช่คนปกติ)

คำอธิบายภาพ

- แหล่งที่มาของรูปภาพ: แพ็คเกจอิโมติคอนนี้เป็นของฉันเอง P: ) -

อนาคตของ DeFi เกมบล็อกเชน และระบบนิเวศของ dApp ขึ้นอยู่กับขนาดของผู้เล่นที่เข้าสู่ตลาด ซึ่งหมายความว่าเราจำเป็นต้องแก้ปัญหาการเริ่มใช้งานสำหรับผู้เล่นใหม่ และลดเกณฑ์ความรู้ลงเพื่อการดำเนินการที่ปลอดภัย ปัญหาหลักสองประการในขณะนี้คือผู้เล่นต้องมีกระเป๋าเงินดิจิทัลและอีเทอร์บางส่วนเพื่อเริ่มต้น ซึ่งเป็นสิ่งที่หลายคนในอุตสาหกรรมกำลังทำงานอย่างหนักเพื่อเอาชนะ

ก่อนที่จะมีการทำธุรกรรมเมตา การฝากเงินล่วงหน้าจำเป็นต้องดำเนินการบริการข้างต้นให้เสร็จสมบูรณ์ นั่นคือการฝากเงินครั้งแรกของ Ether เข้าในบัญชีของผู้ใช้ปลายทางเพื่ออำนวยความสะดวกในการทำธุรกรรม Lambda Sensui จาก Uport เป็นแอปพลิเคชันทั่วไปในเรื่องนี้

ทำให้สำเร็จ

หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับธุรกรรมเมตา คุณสามารถอ่านบทความต่อไปนี้ ผู้เขียนซึ่งเป็นเกณฑ์มาตรฐานในชุมชน - Austin Griffith

ธุรกรรม Ethereum Meta: ลดอุปสรรคในการทำให้ Ethereum เป็นที่นิยม (หมายเหตุบรรณาธิการ: ดูท้ายบทความสำหรับการแปลภาษาจีน)

ทำให้สำเร็จ

บนเครือข่าย การนำธุรกรรมเมตาไปใช้ต้องมีมาตรฐานการเข้ารหัสเพื่อเข้ารหัสข้อมูลธุรกรรมที่ส่งโดยผู้ส่งดั้งเดิม เพื่อให้สัญญาเป้าหมายสามารถกู้คืนลายเซ็นและข้อมูลได้โดยไม่ได้รับผลกระทบจาก msg.sender (เช่น ผู้ส่งต่อ) อย่างไรก็ตาม ผู้ใช้ปลายทางแบบออฟไลน์ต้องเชื่อมต่อกับรีเลย์ผ่าน API หรือโปรโตคอลการสื่อสาร และตัวส่งต่อเองก็ต้องมีอีเธอร์และโครงสร้างพื้นฐานเพื่อดึงข้อมูลและส่งต่อธุรกรรมเมตา

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

กระเป๋าเงินสัญญา

องค์กรหลายแห่งเช่น Dapper Labs, Gnosis และ Argent กำลังเปิดตัวกระเป๋าเงินสัญญาที่มุ่งสร้างสมดุลระหว่างประสบการณ์ผู้ใช้และความปลอดภัย กระเป๋าเงินสัญญาโฮสต์เงินของผู้ใช้ในสัญญาอัจฉริยะ และฟังก์ชันในการส่งธุรกรรมและการปกป้องความปลอดภัยของบัญชีในสัญญาอาจเกินระดับของโปรโตคอล Ethereum

คำอธิบายภาพ

- ที่มา: Dapper Labs -

ด้วยวิธีนี้ ธุรกรรมสามารถส่งได้แม้ไม่มี Ether ในบัญชี และไม่มีความจำเป็นที่อุตสาหกรรมจะต้องยอมรับมาตรฐานเดียวกัน - กระเป๋าเงินสัญญาสามารถเป็นเหมือนบัญชีเจ้าของภายนอก (เช่น ที่อยู่ผู้ใช้ปกติที่ควบคุมโดยคีย์มาตรฐาน คู่, EOA) เพื่อเรียกสัญญาอื่นๆ นอกจากนี้ ยังนำชุดคุณสมบัติด้านความปลอดภัย เช่น ไฟร์วอลล์การทำธุรกรรมของ Authereum

คำอธิบายภาพ

- ที่มา: Authereum -

ปัญหาที่เกิดจากกระเป๋าสตางค์สัญญา

สำหรับกระเป๋าเงินสัญญาและนวัตกรรมต่างๆ เช่น Ethereum Naming Service (ENS) มีข่าวลือมากมายในชุมชน Ethereum อย่างไรก็ตาม เมื่อมีผู้ใช้จำนวนมากใช้โดเมน ENS เป็นข้อมูลประจำตัวสำหรับกิจกรรมบนเครือข่ายทั้งหมด (และใช้ชื่อจริงสำหรับส่วนที่อ่านได้ของโดเมน) ความกังวลเรื่องความเป็นส่วนตัวและความปลอดภัยจำนวนมากจึงเริ่มปรากฏขึ้น

ที่อยู่กระเป๋าเงิน Ethereum นั้น "หลอกไม่ระบุชื่อ" (และค่อนข้างเป็นส่วนตัว) แต่ผู้ให้บริการซอฟต์แวร์กระเป๋าเงินหลายรายกำลังสนับสนุนให้ผู้ใช้รับที่อยู่ ENS โดยไม่แจ้งให้ทราบถึงผลที่ตามมาจากการทำเช่นนั้น กล่าวโดยย่อ บันทึกการทำธุรกรรมของบัญชี Ethereum (รวมถึงพอร์ตการลงทุนและบันทึกการโต้ตอบกับ dApps) จะถูกเผยแพร่บนเครือข่าย หลังจากที่ที่อยู่ลงทะเบียนชื่อโดเมน ENS กิจกรรมการทำธุรกรรมเหล่านี้จะเชื่อมโยงกับชื่อโดเมน ENS นี้ ชื่อ ENS ที่ผู้ใช้ลงทะเบียนน่าจะเป็นชื่อที่ผู้ใช้เคยใช้แล้วในบริการอื่นหรือในชีวิตจริง นี่คือเหตุผลหลักที่ฉันสงสัยเกี่ยวกับการผูก ENS กับที่อยู่กระเป๋าเงิน (สำหรับใช้ส่วนตัว)

อย่างไรก็ตาม ฉันทั้งหมดสำหรับกระเป๋าเงินสัญญา/กระเป๋าเงินหลายใบที่ใช้ ENS เพื่อระบุสัญญาอัจฉริยะเพื่อป้องกันการฉ้อโกง และสำหรับองค์กรที่อาจได้รับประโยชน์จากการดำเนินงานที่โปร่งใส 🙌

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

คำอธิบายภาพ

- กระเป๋าเงินที่กำหนดขึ้นตามลำดับชั้นเป็นโซลูชันความเป็นส่วนตัวในสิทธิของตนเอง และยังใช้กับกระเป๋าเงิน Ethereum ที่มา: Casa-

สมมติว่าผู้ใช้ทุกคนในระบบนิเวศของ Ethereum มีกระเป๋าเงินสัญญาที่สอดคล้องกันสำหรับแต่ละ dApp ที่โต้ตอบกับพวกเขา เพื่อให้พวกเขาสามารถใช้ฟังก์ชันธุรกรรมเมตาและปกป้องความเป็นส่วนตัวได้ ดังนั้น มันจะสมเหตุสมผลกว่าสำหรับสัญญาอัจฉริยะที่จะใช้มาตรฐานทั่วไป .

สู่มาตรฐานสากล

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

• ตามแนวคิดที่เรานำเสนอ Vincent ที่ปรึกษาทั่วไปของเราเสนอแนวคิด: ให้นักพัฒนา dApp ฝากเงินล่วงหน้าสำหรับผู้ใช้เพื่อชำระค่าน้ำมัน และผู้ใช้แลกเปลี่ยนเป็นสกุลเงินตามกฎหมาย เพื่อหลีกเลี่ยงไม่ให้โครงการ dApp ถูกระบุว่าเป็นการแลกเปลี่ยน สิ่งเหล่านี้ อีเทอร์สามารถใช้ได้ภายใน dApp เท่านั้น นี่คือกลไกที่เราหวังว่าจะสนับสนุนในมาตรฐาน metatransaction ทั่วไปในอนาคต (นี่เป็นสิ่งที่เราคิดขึ้นมาเมื่อปีที่แล้วตอนที่เรากำลังทำงานอย่างอื่นอยู่) เครือข่ายสถานีบริการน้ำมันสนับสนุนแนวคิดนี้ด้วยการใช้งานเมธอด

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

• มีกลไกรองรับวิธีการชำระเงินคืน/การชำระเงินของผู้ส่งต่อทางเลือก

วิธีที่เหมาะสมสำหรับการทำงานในสัญญาอัจฉริยะสำหรับสินทรัพย์ dApps และ DeFi (แทนที่จะเป็นมาตรฐานกระเป๋าเงินสัญญา)

กลไกที่สนับสนุนการแบทช์ธุรกรรมภายในสัญญาเป้าหมายหรือสัญญาที่ใช้เพื่อถ่ายทอดธุรกรรม

ethereum/EIP-1613：Gas Station Network

ethereum/EIP-712

ภาพรวมของข้อเสนอของเรา

อย่างที่คุณเห็น เราสนับสนุนแนวคิดที่เสนอโดยเครือข่ายสถานีบริการน้ำมันเป็นอย่างยิ่ง เมธอด getSender() และ getMessageData() ที่ให้บริการโดย RelayRecipient ใช้อินเทอร์เฟซแบบรวม ทำให้ธุรกรรมเมตาของสัญญาทั้งหมดเข้ากันได้ อย่างไรก็ตาม แนวทางเหล่านี้ในรูปแบบปัจจุบันประสบกับข้อบกพร่องสองประการ นั่นคือ ไม่สามารถป้องกันการโจมตีแบบฟิชชิงและการเล่นซ้ำได้ รายละเอียด:

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

Makerdao/dss：https://github.com/makerdao/

คำอธิบายภาพ

- ส่วนต่อประสาน Metamask สำหรับการเซ็นชื่อข้อมูลโดยใช้เมธอด signTypedData_v4 ที่มา: Metamask -

สัญญาที่รองรับ EIP-712 จำเป็นต้องตรวจสอบว่าตัวคั่นชื่อโดเมนตรงกับตัวสัญญา และปฏิเสธการทำธุรกรรมหากไม่ตรงกัน คุณสามารถดูสิ่งนี้ได้ในรหัสสำหรับสัญญา Dai ที่แสดงด้านล่าง เราต้องการรวม EIP-712 เข้ากับ getSender() และ getMessageData() เพื่อให้การตรวจสอบนี้ดำเนินการได้ในทุกการเรียกใช้เมธอด - หากลายเซ็นไม่ตรงกัน ให้ปฏิเสธการทำธุรกรรม คุณสามารถคลิกที่ลิงค์ด้านล่างเพื่อดูรหัสสำหรับฟังก์ชั่นนี้ (ขออภัย ไม่สามารถแสดงรูปแบบของรหัสที่ฝังของบทความได้อย่างถูกต้อง)

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

ธุรกรรมเมตามักเป็นส่วนหนึ่งของชุดการดำเนินการที่อาจขึ้นอยู่กับธุรกรรมก่อนหน้า ตัวอย่างเช่น ในกรณีพิสูจน์แนวคิดที่เราสร้างขึ้น ผู้ใช้สามารถฝาก xDai ไว้ในโปรโตคอล Compound บน mainnet หมายความว่าเราให้สัญญา cDai เข้าถึงเงินทุนของผู้ใช้ จากนั้นจึงเรียกใช้เมธอด mint() เพื่อฝากเงินเข้าในโปรโตคอลการให้ยืม

หากบัญชีของผู้ใช้ไม่ใช่กระเป๋าเงินสัญญา จำเป็นต้องมีการดำเนินการหลายชุดเพื่อให้กระบวนการนี้เสร็จสมบูรณ์: ขั้นแรก ต้องเรียกใช้เมธอด Approve()/permit() ผ่านธุรกรรม จากนั้นต้องเรียกใช้เมธอด mint() หลังจาก การทำธุรกรรมเป็นแพ็คเกจ ด้วยกระเป๋าเงินสัญญา คุณสามารถประมวลผลธุรกรรมเหล่านี้เป็นชุดได้โดยการเรียกวิธีสัญญาพิเศษ

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

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

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

ผู้รวบรวมรีเลย์ควรสนับสนุนการแบทช์ธุรกรรมและเสริม sendRawTransaction() ด้วยเมธอด sendRawTransactionSet() สำหรับการส่งธุรกรรมหลายรายการโดยผู้ใช้คนเดียวกัน ควรใช้เมธอด sendRawTransactionSetPlural() เพื่ออำนวยความสะดวกในการทำธุรกรรมการส่งต่อเป็นชุดจากผู้ใช้หลายคนเพื่อลดต้นทุนก๊าซ

- ที่มา: Tabey -

สรุป

หากสามารถรับทุนจากธุรกรรมในชุดธุรกรรมได้ก็สามารถทำได้ด้วยการเปลี่ยนแปลงเวิร์กโฟลว์ปัจจุบันของตัวรวมรีเลย์เพียงเล็กน้อยเท่านั้น Relayer สามารถส่งค่าพารามิเตอร์ gasPrice และค่าธรรมเนียม acceptRelayCall() เป็น 0 ผู้ถ่ายทอดสามารถแยกธุรกรรมจากชุดธุรกรรมได้อย่างต่อเนื่องและประมวลผลตามมาตรฐานจนกว่าจะเสร็จสิ้น

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

สรุป