Kiểm toán Uma - Giai đoạn 6

Giới thiệu

UMA là một nền tảng cho phép người dùng tham gia các hợp đồng tài chính giảm thiểu độ tin cậy trên chuỗi khối Ethereum. Trước đây chúng tôi đã kiểm toán oracle phi tập trung, một mẫu hợp đồng tài chính cụ thể, một số yêu cầu kéo đặc biệt, mẫu Đa đảng vĩnh viễn, các yêu cầu kéo tăng dần khác nhau trong thời gian tương tác lâu hơn và cây cầu được bảo hiểm.

Trong cuộc kiểm tra này, chúng tôi đã xem xét hợp đồng đề xuất quản trị mới, cơ chế mở rộng hệ sinh thái UMA trên nhiều chuỗi, cơ chế phân phối phần thưởng cho chủ sở hữu mã thông báo ERC721 theo thông số kỹ thuật ngoài chuỗi và bản cập nhật cho cầu nối được bảo hiểm để hỗ trợ WETH trên chuỗi Lạc quan.

Cam kết đã được kiểm toán là 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc và phạm vi bao gồm các hợp đồng sau:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (không bao gồm hợp đồng thử nghiệm và Đa giác)
• financial-templates/optimistic-rewarder/* (không bao gồm hợp đồng thử nghiệm)

Chúng tôi cũng đã xem xét những thay đổi đối với các tập tin Solidity trong Yêu cầu kéo 3611.

Tất cả các mã bên ngoài và các phần phụ thuộc của hợp đồng đều được coi là hoạt động như được ghi trong tài liệu.

Tổng quan về hệ thống

Hiện tại Governance hợp đồng cho phép Tổ chức Phòng thí nghiệm Rủi ro đề xuất các hành động quản trị mới có thể được chủ sở hữu mã thông báo UMA phê duyệt. Cái mới Proposer hợp đồng nhằm đảm nhận vai trò là người đề xuất, cho phép bất kỳ ai đưa ra đề xuất mới miễn là họ đưa ra một cam kết sẽ bị hy sinh nếu đề xuất thất bại. Không có động lực cụ thể cho việc đưa ra đề xuất. Mục đích là để đảm bảo rằng chỉ những hành động có nhiều khả năng được chấp nhận mới được đề xuất.

Cơ chế chuỗi chéo mới cho phép chuyển đề xuất quản trị từ mạng chính Ethereum sang chuỗi Optimism và Arbitrum. Bằng cách này, cơ chế quản trị UMA trên lớp 1 có thể được sử dụng để quản lý các hợp đồng UMA trên chuỗi lớp 2 được hỗ trợ. Cơ chế này cũng cho phép chuyển tiếp các yêu cầu về giá và giải pháp giữa các lớp, do đó, Optimistic Oracles trên chuỗi lớp 2 có thể được bảo mật bằng Cơ chế xác minh dữ liệu mạng chính giống như cách mà Optimistic Oracle lớp 1 được bảo mật bởi DVM.

Điều đáng chú ý là những tin nhắn này được gửi bằng cơ chế cầu nối gốc, có nghĩa là chúng bị giới hạn bởi các đặc điểm của chuỗi lớp 2 có liên quan. Đặc biệt, các tin nhắn từ lớp 2 đến lớp 1 có thể mất một tuần hoặc lâu hơn để truyền qua cầu. Hơn nữa, cơ chế quản trị UMA hỗ trợ các đề xuất bao gồm nhiều giao dịch được đặt hàng, nhưng điều này chỉ hạn chế thứ tự mà chúng có thể được thêm vào cầu nối. Có thể một số giao dịch đó được thực hiện theo thứ tự khác hoặc hoàn toàn không được thực hiện trên lớp 2.

Hợp đồng Optimistic Rewarder chỉ đơn giản là tạo ra các token ERC721 cho bất kỳ ai yêu cầu chúng. Nó cũng cho phép mọi người liên kết dữ liệu tùy ý với bất kỳ mã thông báo nào và gửi các mã thông báo ERC20 khác nhau để phân phối dưới dạng phần thưởng. Việc giải thích dữ liệu tùy ý và phân phối phần thưởng dự kiến ​​giữa những người nắm giữ mã thông báo được xác định bằng cách sử dụng quy trình ngoài chuỗi không xác định. Bất kỳ ai cũng có thể đưa ra khiếu nại rằng mã thông báo ERC721 cụ thể sẽ được hưởng một bộ phần thưởng nếu họ sẵn sàng gửi trái phiếu. Cơ chế Optimistic Oracle tiêu chuẩn được sử dụng để cho phép người khác tranh chấp khiếu nại và việc này sẽ được DVM giải quyết. Các khiếu nại không bị tranh chấp kịp thời được coi là hợp lệ và hợp đồng sẽ phân phối phần thưởng tương ứng. Hạn chế duy nhất (để đơn giản hóa việc tính toán) là không thể sử dụng mã thông báo trái phiếu oracle làm mã thông báo phần thưởng.

Cuối cùng, PR3611 sửa đổi cơ chế cầu nối được bảo hiểm để tránh gửi WETH qua cầu nối mã thông báo Optimism vốn không được hỗ trợ. Thay vào đó, bất kỳ L2 WETH nào được gửi vào hộp ký gửi Optimism sẽ được mở thành L2 ETH trước khi chuyển qua cầu. Ở lớp 1, ETH được chuyển đổi thành WETH trước khi được chuyển tiếp đến nhóm cầu WETH.

Mức độ nghiêm trọng

[C01] Không thể tranh chấp phần thưởng không hợp lệ

Khi tranh chấp yêu cầu khen thưởng, OptimisticRewardBase hợp đồng đầu tiên kích hoạt một đề xuất trên SkinnyOptimisticOracle và sau đó tranh chấp đề xuất đó. Tuy nhiên, lời đề nghị đặt thời gian hết hạn như một sự bù đắp cho thời điểm (tranh chấp) hiện tại, trong khi tranh chấp chỉ định thời hạn như một sự bù đắp so với thời điểm yêu cầu phần thưởng ban đầu. Trong hầu hết các trường hợp, sự khác biệt này sẽ ngăn nhà tiên tri xác định đề xuất đang bị tranh chấp, điều đó có nghĩa là các tranh chấp hợp lệ sẽ không được xử lý và các yêu cầu phần thưởng không hợp lệ sẽ được chấp nhận.

Hãy cân nhắc việc cập nhật lời gọi tranh chấp để chỉ định chính xác đề xuất bị tranh chấp.

Cập nhật: Đã sửa lỗi kể từ khi cam kết 9e15557 in PR3690.

[C02] Liên tục giải quyết kiến ​​nghị

Sản phẩm resolveProposal chức năng của Proposer hợp đồng chỉ cần xác nhận rằng oracle đã được giải quyết nhưng không kiểm tra xem trái phiếu đã được phân phối chưa. Điều này có nghĩa là cùng một đề xuất có thể được giải quyết nhiều lần, dẫn đến việc thanh toán trái phiếu trùng lặp. Hãy xem xét gắn cờ hoặc xóa các đề xuất hiện có khi chúng được giải quyết.

Cập nhật: Đã sửa lỗi kể từ khi cam kết b152718 in PR3689.

Mức độ nghiêm trọng cao

Không có.

Mức độ nghiêm trọng trung bình

[M01] Tham số sự kiện không chính xác

Sản phẩm OptimisticRewarderBase hợp đồng xác định một Requested sự kiện được phát ra từ requestRedemption chức năng khi yêu cầu đổi quà. Sự kiện này được xác định để phát ra thời gian hết hạn đổi thưởng làm tham số cuối cùng của nó. Tuy nhiên, khi sự kiện được phát ra, tham số cuối cùng của nó được đặt không chính xác thành thời điểm hiện tại.

Tương tự như vậy Redeemed sự kiện đọc thời gian hết hạn sau khi bản ghi bị xóa, do đó nó sẽ được đặt không chính xác thành 0.

Vì sự kiện này có thể được sử dụng để kích hoạt tính toán ngoài chuỗi, hãy cân nhắc việc cập nhật giá trị được phát ra một cách thích hợp.

Cập nhật: Đã sửa lỗi kể từ khi cam kết f04eef9 in PR3694.

Mức độ nghiêm trọng thấp

[L01] Thiếu phát ra sự kiện sau khi tranh chấp việc quy đổi

Sản phẩm OptimisticRewarderBase hợp đồng xác định một Disputed sự kiện điều đó dự định sẽ được kích hoạt nếu việc quy đổi bị tranh chấp. Tuy nhiên, sự kiện này không được phát ra bên trong hoặc bên ngoài OptimisticRewarderBase hợp đồng.

Hãy cân nhắc việc phát ra sự kiện sau khi những thay đổi nhạy cảm diễn ra trong dispute chức năng, để tạo điều kiện thuận lợi cho việc theo dõi và thông báo cho khách hàng ngoài chuỗi theo dõi hoạt động của hợp đồng.

Cập nhật: Đã sửa lỗi kể từ khi cam kết c275e92 in PR3695.

[L02] Bảo vệ quay lại không nhất quán

Sản phẩm Optimism_ParentMessenger và Arbitrum_ParentMessenger hợp đồng áp dụng không nhất quán nonReentrant bổ nghĩa. Hãy xem xét đưa nó vào tất cả các chức năng công cộng.

Cập nhật: Đã sửa lỗi kể từ khi cam kết 6275c39 in PR3677.

[L03] Bình luận gây hiểu lầm

Dưới đây là một số nhận xét sai lệch mà chúng tôi đã xác định được trong quá trình xem xét:

• ChildMessengerConsumerInterface.sol:
  • Dòng 5 nói "người đưa tin cha mẹ" thay vì "người đưa tin con"
• GovernorSpoke.sol:
  • Dòng 49-51 liên kết đến một Gnosis mặc dù nhận xét cho biết đoạn mã đã được sao chép từ Governor.sol. Ngoài ra, đoạn mã không giống với đoạn mã trong Governor.sol

Cập nhật: Đã sửa lỗi kể từ khi cam kết cc350f9 in PR3678.

[L04] Thiếu tem dữ liệu phụ trợ

Khi yêu cầu giá trên OracleSpoke hợp đồng, dữ liệu phụ trợ được cung cấp được đóng dấu với mã định danh chuỗi con. Tuy nhiên, hasPrice và getPrice các chức năng không đóng dấu dữ liệu phụ trợ khi xác định yêu cầu giá. Điều này buộc các hợp đồng kêu gọi phải tự dán tem, gây ra sự mâu thuẫn giữa cơ chế yêu cầu giá và cơ chế truy hồi giá. Hãy cân nhắc việc dán tem vào hasPrice và getPrice chức năng.

Cập nhật: Đã sửa lỗi kể từ khi cam kết fdb845d in PR3668.

[L05] Thiếu tham số NatSpec

Nhiều chức năng trong OptimisticRewarderBase hợp đồng đang thiếu @return tham số trong nhận xét Đặc điểm kỹ thuật tự nhiên của họ. Hãy xem xét bao gồm nó cho đầy đủ.

Cập nhật: Đã sửa lỗi kể từ khi cam kết 8920f38 in PR3679.

[L06] Trợ cấp thặng dư

Để triệu hồi Nhà tiên tri lạc quan, OptimisticRewarderBase hợp đồng cấp cho nó một khoản trợ cấp mã thông báo, vì vậy nó có thể kéo các khoản thanh toán trái phiếu. Nếu đề xuất thất bại, việc đổi phần thưởng bị hủy nhưng phụ cấp không được thiết lập lại. Do đó, Optimistic Oracle sẽ giữ lại một khoản trợ cấp còn lại không cần thiết cho đến lần tranh chấp tiếp theo được kích hoạt. Xem xét thu hồi trợ cấp nếu đề xuất không thành công.

Cập nhật: Đã sửa lỗi kể từ khi cam kết c2d444b in PR3698.

[L07] Địa chỉ hoàn tiền không hợp lệ

Địa chỉ L2 hoàn tiền của Arbitrum_ParentMessenger được khởi tạo cho chủ sở hữu hợp đồng, đó phải là Thống đốc L1. Tương tự, các setRefundL2Address có một bình luận nói rằng nó nên được giao cho thống đốc. Tuy nhiên, khi truyền thông điệp qua bridge, giá trị này là được đặt làm người dùng L2, là địa chỉ trên Arbitrum nhận số tiền dư sau khi yêu cầu được giải quyết. Vì địa chỉ thống đốc L1 sẽ không thể truy cập được trên Arbitrum nên mọi khoản tiền được gửi đến địa chỉ này sẽ bị mất.

Hãy cân nhắc việc đặt nó thành địa chỉ L2 hợp lệ.

Cập nhật: Đã sửa lỗi kể từ khi cam kết b3f2dd1 in PR3687.

[L08] Cơ chế thay đổi tin nhắn con

Sản phẩm GovernorSpoke và OracleSpoke mỗi hợp đồng đều khởi tạo trình nhắn tin con trong hàm tạo mà không có cơ chế cập nhật nó. Điều này có nghĩa là khi tin nhắn trẻ em đã được thay đổi, cả hai hợp đồng nói đều trở nên lỗi thời.

Vì hợp đồng nan hoa có thể ổn định hơn so với trình nhắn tin nên hãy cân nhắc việc đưa vào cơ chế cập nhật trình nhắn tin trên các nan hoa.

Cập nhật: Đã sửa lỗi kể từ khi cam kết 7c9e061 in PR3688.

Ghi chú & Thông tin bổ sung

[N01] Thay đổi token trái phiếu

Sản phẩm Proposer hợp đồng bao gồm một cơ chế để chủ sở hữu thay đổi quy mô của trái phiếu đề xuất. Xem xét liệu họ có thể thay đổi mã thông báo trái phiếu hay không. Lưu ý rằng điều này sẽ yêu cầu một cơ chế xác định loại tiền tệ trái phiếu chính xác khi các đề xuất hiện tại được giải quyết.

Cập nhật: Không phải là một vấn đề. Tuyên bố của UMA về vấn đề này:

N01 khuyến nghị cho phép hợp đồng người đề xuất thay đổi mã thông báo trái phiếu thành một thứ khác ngoài UMA. Chúng tôi không có ý định hỗ trợ bất kỳ token nào ngoài $UMA cho chức năng này và do đó đã chọn không thực hiện bất kỳ thay đổi nào đối với vấn đề này. Hơn nữa, một mã thông báo duy nhất cho mỗi hợp đồng giữ cho logic này đơn giản nhất có thể. Cuối cùng, nếu cần thay đổi (ví dụ: trong trường hợp di chuyển mã thông báo), chúng tôi chỉ có thể triển khai hợp đồng người đề xuất mới với mã thông báo khác và bắt đầu đề xuất di chuyển hệ thống để sử dụng mã đó.

[N02] Giao diện chưa hoàn chỉnh

Sản phẩm ChildMessengerInterface không chỉ định một processMessageFromCrossChainParent chức năng, mặc dù nó được cho là tồn tại bởi các sứ giả gốc. Hãy xem xét bao gồm nó cho đầy đủ.

Cập nhật: Không cố định. Tuyên bố của UMA về vấn đề này:

Chúng tôi cố tình chọn để giao diện này không nhất quán vì việc triển khai giao diện này trong ChildMessengerInterface sẽ phá vỡ tính tương thích với Polygon_ChildMessenger vì phương thức của Polygon để xử lý thông báo từ các chuỗi khác yêu cầu logic tùy chỉnh trong đó một phương thức nội bộ được gọi là _processMessageFromRoot.

[N03] Giao diện không chính xác

Sản phẩm GovernorSpoke hợp đồng sai sử dụng ChildMessengerConsumerInterface kiểu để mô tả nó messenger Biến đổi. Hãy cân nhắc việc sử dụng ChildMessengerInterface thay thế.

Cập nhật: Đã sửa lỗi kể từ khi cam kết f31a527 in PR3680.

[N04] Kéo token về Store

Trong một kiểm toán trước đó chúng tôi đã đặt câu hỏi về mục đích của Store hợp đồng của payOracleFeesErc20 chức năng (ở số L19). Đội ngũ UMA đã chọn giữ chức năng để chuẩn hóa giao diện cho những sửa đổi tiềm năng trong tương lai. Vì mục đích của chức năng này không được xác định đầy đủ nên không rõ liệu nó có được kích hoạt khi Proposer hợp đồng tịch thu trái phiếu. Nó có thể nên được sử dụng khi OracleHub trả tiền cho yêu cầu giá. Xem xét liệu chức năng này có nên được sử dụng trong một trong hai trường hợp hay không.

Cập nhật: Được thừa nhận. Tuyên bố của UMA về vấn đề này:

N04 khuyến nghị sử dụng phương thức payOracleFeeErc20 của Cửa hàng để thanh toán phí trong cả hợp đồng Người đề xuất và OracleHub để phù hợp với cách sử dụng của Cửa hàng. Chúng tôi đã chọn không sử dụng chức năng này vì điều đó có nghĩa là cần phải nhập một giao diện bổ sung (cho cửa hàng) và yêu cầu chuyển số tiền trái phiếu sang một Điểm cố định (cũng sẽ yêu cầu nhập bổ sung. Để giữ cho mã đơn giản và rõ ràng chúng tôi đã chọn không làm điều này. Phản hồi của OZ về payOracleFeeErc20 trong giai đoạn kiểm tra 1 vào tháng 2020 năm XNUMX đã xác nhận rằng phương pháp này không thực sự hữu ích, khiến cho kiểu tích hợp này khó giải thích hơn.

[N05] VIỆC CẦN LÀM trong mã

Có những nhận xét “TODO” trong cơ sở mã cần được theo dõi trong các vấn đề tồn đọng của dự án. Ví dụ:

• Dòng 37 of Arbitrum_ParentMessenger hợp đồng
• Dòng 25 of Optimism_ChildMessenger hợp đồng
• đường 83 và 146 of OracleHub hợp đồng.

Trong quá trình phát triển, việc mô tả rõ ràng các nhận xét “TODO” sẽ giúp quá trình theo dõi và giải quyết chúng trở nên dễ dàng hơn. Nếu không có thông tin đó, những nhận xét này có thể có xu hướng bị hỏng và thông tin quan trọng về bảo mật của hệ thống có thể bị lãng quên vào thời điểm nó được đưa vào sản xuất.

Những nhận xét TODO này phải có mô tả ngắn gọn về nhiệm vụ đang chờ thực hiện và liên kết đến vấn đề tương ứng trong kho dự án.

Hãy cân nhắc việc cập nhật các nhận xét TODO để thêm thông tin này. Để hoàn thiện và truy xuất nguồn gốc, có thể thêm chữ ký và dấu thời gian. Ví dụ:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Cập nhật: Đã sửa lỗi kể từ khi cam kết 5d57b5b in PR3684.

[N06] Lỗi đánh máy

Cơ sở mã chứa các lỗi đánh máy sau:

• Trong tạp chí Admin_ChildMessenger hợp đồng, impleenting nên là implementing
• Trong tạp chí OptimisticRewarderBase hợp đồng, timestap nên là timestamp.
• Trong tạp chí OptimisticRewarderBase hợp đồng, liveness liveness nên là liveness.
• Trong tạp chí GovernorSpoke hợp đồng, only called nên là only be called.
• Trong tạp chí Optimism_ChildMessenger hợp đồng:

Cập nhật: Đã sửa lỗi kể từ khi cam kết 9b92b0b in PR3681.

[N07] Hàng nhập khẩu chưa qua sử dụng

Để cải thiện khả năng đọc mã, hãy xem xét loại bỏ các mục nhập không sử dụng sau:

Cập nhật: Đã sửa lỗi kể từ khi cam kết 40b7221 in PR3682.

[N08] Thứ tự giao dịch L2

Sản phẩm Governor đảm bảo các giao dịch trong một đề xuất được thực hiện theo thứ tự. Tuy nhiên, khi những giao dịch đó liên quan đến các giao dịch xuyên chuỗi, điều này chỉ đảm bảo rằng chúng đến hợp đồng cầu nối L1 theo đúng thứ tự. Trong trường hợp Trọng tài, chúng có thể được sắp xếp lại trước khi được hoàn thiện trên L2. Do đó, các đề xuất quản trị nên được xây dựng để cho phép khả năng sắp xếp lại các giao dịch L2.

Cập nhật: Đã sửa lỗi kể từ khi cam kết 0fb2e7b in PR3703. Các GovernorHub bây giờ có thể chuyển tiếp một loạt các giao dịch L2.

Kết luận

Hai vấn đề nghiêm trọng đã được tìm thấy trong cơ sở mã. Một vấn đề có mức độ nghiêm trọng trung bình và một số lỗ hổng nhỏ đã được tìm thấy và các đề xuất khắc phục đã được đề xuất.

Nguồn: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6