Uma Audit – ระยะที่ 6

บทนำ

UMA เป็นแพลตฟอร์มที่อนุญาตให้ผู้ใช้เข้าสู่สัญญาทางการเงินที่ลดความน่าเชื่อถือบน Ethereum blockchain ก่อนหน้านี้เราได้ตรวจสอบ oracle ที่กระจายอำนาจ, เทมเพลตสัญญาทางการเงินโดยเฉพาะ, คำขอดึงเฉพาะกิจบางรายการ, เทมเพลต Perpetual Multiparty, คำขอดึงที่เพิ่มขึ้นต่างๆ ในช่วงเวลาที่ยาวนานขึ้น และ สะพานผู้เอาประกันภัย.

ในการตรวจสอบนี้ เราได้ตรวจสอบสัญญาข้อเสนอการกำกับดูแลใหม่ กลไกในการขยายระบบนิเวศ UMA ในหลายสายโซ่ กลไกในการกระจายรางวัลไปยังผู้ถือโทเค็น ERC721 ตามข้อกำหนดนอกสายโซ่ และการอัปเดตสะพานผู้ประกันตนเพื่อรองรับ WETH บนห่วงโซ่การมองในแง่ดี

คอมมิตที่ตรวจสอบแล้วคือ 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc และขอบเขตรวมถึงสัญญาดังต่อไปนี้:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (ไม่รวมการทดสอบและสัญญารูปหลายเหลี่ยม)
• financial-templates/optimistic-rewarder/* (ไม่รวมสัญญาทดสอบ)

นอกจากนี้เรายังตรวจสอบการเปลี่ยนแปลงของไฟล์ความแข็งแกร่งใน ดึงคำขอ 3611.

รหัสภายนอกและการอ้างอิงสัญญาทั้งหมดถูกถือว่าทำงานตามเอกสาร

ภาพรวมของระบบ

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

กลไกข้ามสายโซ่ใหม่ช่วยให้ข้อเสนอการกำกับดูแลสามารถส่งผ่านจากเครือข่ายหลัก Ethereum ไปยังกลุ่ม Optimism และ Arbitrum ด้วยวิธีนี้ กลไกการกำกับดูแล UMA บนเลเยอร์ 1 สามารถใช้เพื่อควบคุมสัญญา UMA บนเชนเลเยอร์ 2 ที่รองรับ กลไกนี้ยังอนุญาตให้มีการส่งต่อคำขอราคาและความละเอียดระหว่างเลเยอร์ ดังนั้น Optimistic Oracles บนเชนเลเยอร์ 2 สามารถรักษาความปลอดภัยโดยกลไกการตรวจสอบข้อมูล mainnet ในลักษณะเดียวกับที่ DVM ของ Optimistic Oracle ระดับ 1 นั้นปลอดภัย

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

สัญญา Optimistic Rewarder จะสร้างโทเค็น ERC721 ให้กับทุกคนที่ร้องขอ นอกจากนี้ยังอนุญาตให้ทุกคนเชื่อมโยงข้อมูลตามอำเภอใจกับโทเค็นใดๆ และฝากโทเค็น ERC20 ต่างๆ เพื่อแจกจ่ายเป็นรางวัล การตีความข้อมูลตามอำเภอใจและการกระจายรางวัลที่คาดหวังระหว่างผู้ถือโทเค็นนั้นกำหนดโดยใช้ขั้นตอนนอกสายโซ่ที่ไม่ระบุ ทุกคนสามารถอ้างสิทธิ์ได้ว่าโทเค็น ERC721 เฉพาะนั้นเป็นหนี้ชุดของรางวัล หากพวกเขาต้องการฝากพันธบัตร กลไก Optimistic Oracle มาตรฐานใช้เพื่ออนุญาตให้บุคคลอื่นโต้แย้งการอ้างสิทธิ์ ซึ่ง DVM จะแก้ไข การเรียกร้องที่ไม่มีข้อโต้แย้งในเวลาจะถือว่ามีผลสมบูรณ์ และสัญญาจะแจกจ่ายรางวัลให้ตามนั้น ข้อจำกัดเพียงอย่างเดียว (เพื่อทำให้การบัญชีง่ายขึ้น) คือไม่สามารถใช้โทเค็นพันธบัตรของ oracle เป็นโทเค็นรางวัลได้

สุดท้าย PR3611 ปรับเปลี่ยนกลไกสะพานที่ประกันเพื่อหลีกเลี่ยงการส่ง WETH ข้ามสะพานโทเค็น Optimism ซึ่งไม่ได้รับการสนับสนุน แต่ L2 WETH ใดๆ ที่ฝากไว้ในกล่องฝาก Optimism จะถูกแกะไปที่ L2 ETH ก่อนเปลี่ยนผ่าน ในเลเยอร์ 1 ETH จะถูกแปลงเป็น WETH ก่อนที่จะส่งต่อไปยังพูลบริดจ์ของ WETH

ความรุนแรงที่สำคัญ

[C01] ไม่สามารถโต้แย้งรางวัลที่ไม่ถูกต้องได้

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

พิจารณาปรับปรุงการเรียกร้องข้อพิพาทให้ระบุข้อเสนอที่จะโต้แย้งได้อย่างถูกต้อง

ปรับปรุง: แก้ไขเมื่อกระทำ 9e15557 in PR3690.

[C02] แก้ไขข้อเสนอซ้ำๆ

พื้นที่ resolveProposal ฟังก์ชันของ Proposer สัญญา เพียงแค่ตรวจสอบ ว่า oracle ได้แก้ไขแล้ว แต่ไม่ตรวจสอบว่ามีการแจกจ่ายพันธบัตรหรือไม่ ซึ่งหมายความว่าสามารถแก้ไขข้อเสนอเดียวกันได้หลายครั้ง ส่งผลให้มีการจ่ายพันธบัตรซ้ำกัน พิจารณาตั้งค่าสถานะหรือลบข้อเสนอที่มีอยู่เมื่อได้รับการแก้ไข

ปรับปรุง: แก้ไขเมื่อกระทำ b152718 in PR3689.

ความรุนแรงสูง

ไม่

ความรุนแรงปานกลาง

[M01] พารามิเตอร์เหตุการณ์ไม่ถูกต้อง

พื้นที่ OptimisticRewarderBase สัญญากำหนด a Requested เหตุการณ์ ที่ปล่อยออกมาจาก requestRedemption ฟังก์ชั่นเมื่อมีการร้องขอการไถ่ถอน เหตุการณ์นี้ถูกกำหนดให้ปล่อย เวลาหมดอายุของการแลกของรางวัล เป็นพารามิเตอร์สุดท้าย อย่างไรก็ตาม, เมื่อเหตุการณ์ถูกปล่อยออกมาพารามิเตอร์สุดท้ายของมันถูกตั้งค่าเป็น .อย่างไม่ถูกต้อง เวลาปัจจุบัน.

ในทำนองเดียวกัน Redeemed เหตุการณ์ อ่านเวลาหมดอายุหลังจากลบเรกคอร์ด ดังนั้นจะถูกตั้งค่าเป็นศูนย์อย่างไม่ถูกต้อง

เนื่องจากเหตุการณ์นี้สามารถใช้เพื่อทริกเกอร์การคำนวณนอกระบบได้ ให้พิจารณาอัปเดตค่าที่ปล่อยออกมาอย่างเหมาะสม

ปรับปรุง: แก้ไขเมื่อกระทำ f04eef9 in PR3694.

ความรุนแรงต่ำ

[L01] ขาดกิจกรรมหลังจากโต้แย้งการแลกของรางวัล

พื้นที่ OptimisticRewarderBase สัญญากำหนด a Disputed เหตุการณ์ ที่ตั้งใจให้เกิดขึ้นหากมีการโต้แย้งการไถ่ถอน อย่างไรก็ตาม เหตุการณ์นี้ไม่ได้เกิดขึ้นภายในหรือภายนอกของ OptimisticRewarderBase สัญญา.

พิจารณาปล่อยเหตุการณ์หลังจากการเปลี่ยนแปลงที่ละเอียดอ่อนเกิดขึ้นใน dispute ฟังก์ชันเพื่ออำนวยความสะดวกในการติดตามและแจ้งลูกค้านอกเครือข่ายตามกิจกรรมของสัญญา

ปรับปรุง: แก้ไขเมื่อกระทำ c275e92 in PR3695.

[L02] ผู้พิทักษ์การกลับเข้าใหม่ที่ไม่สอดคล้องกัน

พื้นที่ Optimism_ParentMessenger และ Arbitrum_ParentMessenger สัญญาที่ใช้ไม่สอดคล้องกัน nonReentrant ตัวแก้ไข พิจารณารวมไว้ในงานสาธารณะทั้งหมด

ปรับปรุง: แก้ไขเมื่อกระทำ 6275c39 in PR3677.

[L03] ความคิดเห็นที่ทำให้เข้าใจผิด

นี่คือความคิดเห็นที่ทำให้เข้าใจผิดบางส่วนที่เราระบุระหว่างการตรวจสอบของเรา:

• ChildMessengerConsumerInterface.sol:
  • บรรทัดที่ 5 พูดว่า "ผู้ส่งสารผู้ปกครอง" แทน "ผู้ส่งสารเด็ก"
• GovernorSpoke.sol:
  • บรรทัดที่ 49-51 ลิงค์ไปยัง Gnosis ไฟล์แม้ว่าความคิดเห็นจะบอกว่าตัวอย่างถูกคัดลอกมาจาก Governor.sol. นอกจากนี้ ข้อมูลโค้ดไม่เหมือนกับตัวอย่างใน Governor.sol

ปรับปรุง: แก้ไขเมื่อกระทำ cc350f9 in PR3678.

[L04] ไม่มีตราประทับข้อมูลเสริม

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

ปรับปรุง: แก้ไขเมื่อกระทำ fdb845d in PR3668.

[L05] ไม่มีพารามิเตอร์ NatSpec

ฟังก์ชั่นมากมายใน OptimisticRewarderBase สัญญา หายไป @return พารามิเตอร์ในความคิดเห็นเกี่ยวกับข้อกำหนดตามธรรมชาติ พิจารณารวมไว้เพื่อความสมบูรณ์

ปรับปรุง: แก้ไขเมื่อกระทำ 8920f38 in PR3679.

[L06] ค่าเผื่อคงเหลือ

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

ปรับปรุง: แก้ไขเมื่อกระทำ c2d444b in PR3698.

[L07] ที่อยู่คืนเงินไม่ถูกต้อง

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

พิจารณาตั้งค่าเป็นที่อยู่ L2 ที่ถูกต้อง

ปรับปรุง: แก้ไขเมื่อกระทำ b3f2dd1 in PR3687.

[L08] กลไกการเปลี่ยนผู้ส่งสารเด็ก

พื้นที่ GovernorSpoke และ OracleSpoke สัญญาแต่ละรายการจะเริ่มต้นโปรแกรมส่งข้อความลูกในตัวสร้างโดยไม่มีกลไกในการอัปเดต ซึ่งหมายความว่าเมื่อ แมสเซนเจอร์เด็กเปลี่ยนไปสัญญาที่พูดทั้งสองจะล้าสมัย

เนื่องจากสัญญาแบบพูดมีแนวโน้มที่จะมีเสถียรภาพมากกว่าผู้ส่งสาร ให้พิจารณารวมกลไกในการอัปเดตผู้ส่งสารบนซี่ล้อด้วย

ปรับปรุง: แก้ไขเมื่อกระทำ 7c9e061 in PR3688.

หมายเหตุและข้อมูลเพิ่มเติม

[N01] เปลี่ยนโทเค็นพันธบัตร

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

ปรับปรุง: ไม่เป็นปัญหา คำชี้แจงของ UMA สำหรับปัญหานี้:

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

[N02] อินเทอร์เฟซไม่สมบูรณ์

พื้นที่ ChildMessengerInterface ไม่ได้ระบุ a processMessageFromCrossChainParent แม้ว่าจะถือว่ามีอยู่โดยผู้ส่งสารหลัก พิจารณารวมไว้เพื่อความสมบูรณ์

ปรับปรุง: ไม่ได้รับการแก้ไข คำแถลงของ UMA สำหรับปัญหานี้:

เราจงใจเลือกที่จะปล่อยให้อินเทอร์เฟซนี้ไม่สอดคล้องกันเนื่องจากการใช้งานสิ่งนี้ภายใน ChildMessengerInterface ทำลายความเข้ากันได้กับ Polygon_ChildMessenger เนื่องจากวิธีการประมวลผลข้อความจากกลุ่มอื่น ๆ ของ Polygon ต้องใช้ตรรกะที่กำหนดเองซึ่งวิธีการภายในเรียกว่า _processMessageFromRoot

[N03] อินเทอร์เฟซไม่ถูกต้อง

พื้นที่ GovernorSpoke สัญญาไม่ถูกต้อง ใช้ ChildMessengerConsumerInterface ชนิด เพื่ออธิบายของมัน messenger ตัวแปร. พิจารณาใช้ ChildMessengerInterface แทน.

ปรับปรุง: แก้ไขเมื่อกระทำ f31a527 in PR3680.

[N04] ดึงโทเค็นไปที่ Store

ใน การตรวจสอบครั้งก่อน เราตั้งคำถามถึงวัตถุประสงค์ของ Store สัญญา payOracleFeesErc20 ฟังก์ชัน (ในฉบับที่ L19) ทีมงาน UMA เลือกที่จะคงไว้ซึ่งหน้าที่ เพื่อสร้างมาตรฐานอินเทอร์เฟซสำหรับการปรับเปลี่ยนในอนาคตที่อาจเกิดขึ้น เนื่องจากไม่ได้ระบุวัตถุประสงค์ของฟังก์ชันอย่างสมบูรณ์ จึงไม่ชัดเจนว่าจะทริกเกอร์เมื่อ Proposer สัญญา ยึดพันธบัตร. ควรใช้เมื่อ OracleHub จ่ายเพื่อขอราคา. พิจารณาว่าควรใช้ฟังก์ชันในสถานการณ์ใด

ปรับปรุง: รับทราบครับ คำชี้แจงของ UMA สำหรับปัญหานี้:

N04 แนะนำให้ใช้วิธี payOracleFeeErc20 ของ Store ในการชำระค่าธรรมเนียมในสัญญา Proposer และ OracleHub เพื่อให้สอดคล้องกับการใช้งาน Store เราเลือกที่จะไม่ใช้ฟังก์ชันนี้เนื่องจากจำเป็นต้องนำเข้าอินเทอร์เฟซเพิ่มเติม (สำหรับร้านค้า) และกำหนดให้ส่งจำนวนพันธบัตรไปยัง FixedPoint (ซึ่งจะต้องมีการนำเข้าเพิ่มเติมด้วย เพื่อให้โค้ดเรียบง่ายและสะอาดอยู่เสมอ เราเลือกที่จะไม่ทำเช่นนี้ ความคิดเห็นของ OZ เกี่ยวกับ payOracleFeeErc20 ในขั้นตอนการตรวจสอบที่ 1 ในเดือนเมษายน 2020 นั้นใช้ได้จริงว่าวิธีนี้ไม่มีประโยชน์จริงๆ

[N05] สิ่งที่ต้องทำในรหัส

มีความคิดเห็น "สิ่งที่ต้องทำ" ในฐานโค้ดที่ควรติดตามในปัญหาที่ค้างอยู่ของโครงการ ตัวอย่างเช่น:

• Line 37 of Arbitrum_ParentMessenger สัญญา
• Line 25 of Optimism_ChildMessenger สัญญา
• เส้น 83 และ 146 of OracleHub สัญญา.

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

ความคิดเห็นเกี่ยวกับ TODO เหล่านี้ควรมีคำอธิบายสั้นๆ เกี่ยวกับงานที่รอดำเนินการ และลิงก์ไปยังปัญหาที่เกี่ยวข้องในที่เก็บโครงการ

พิจารณาอัปเดตความคิดเห็น TODO เพื่อเพิ่มข้อมูลนี้ เพื่อความสมบูรณ์และสามารถตรวจสอบย้อนกลับได้ คุณสามารถเพิ่มลายเซ็นและการประทับเวลาได้ ตัวอย่างเช่น:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

ปรับปรุง: แก้ไขเมื่อกระทำ 5d57b5b in PR3684.

[N06] พิมพ์ผิด

Codebase มีข้อผิดพลาดในการพิมพ์ดังต่อไปนี้:

• ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร Admin_ChildMessenger สัญญา, impleenting ควรจะเป็น implementing
• ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร OptimisticRewarderBase สัญญา, timestap ควรจะเป็น timestamp.
• ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร OptimisticRewarderBase สัญญา, liveness liveness ควรจะเป็น liveness.
• ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร GovernorSpoke สัญญา, only called ควรจะเป็น only be called.
• ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร Optimism_ChildMessenger สัญญา:

ปรับปรุง: แก้ไขเมื่อกระทำ 9b92b0b in PR3681.

[N07] การนำเข้าที่ไม่ได้ใช้

เพื่อปรับปรุงความสามารถในการอ่านโค้ด ให้พิจารณาลบการนำเข้าที่ไม่ได้ใช้ต่อไปนี้:

ปรับปรุง: แก้ไขเมื่อกระทำ 40b7221 in PR3682.

[N08] การสั่งซื้อธุรกรรม L2

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

ปรับปรุง: แก้ไขเมื่อกระทำ 0fb2e7b in PR3703. GovernorHub ตอนนี้สามารถถ่ายทอดอาร์เรย์ของธุรกรรม L2 ได้แล้ว

สรุป

พบปัญหาสำคัญสองประการใน codebase พบปัญหาความรุนแรงปานกลางหนึ่งปัญหาและช่องโหว่เล็กๆ น้อยๆ หลายรายการ และมีการแนะนำสำหรับการแก้ไข

ที่มา: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6