Uma 감사 – 6단계

개요

UMA 사용자가 이더리움 블록체인에서 신뢰가 최소화된 금융 계약을 체결할 수 있는 플랫폼입니다. 우리는 이전에 감사했습니다 분산형 오라클, 특정 금융 계약 템플릿, 일부 임시 풀 요청, 영구 다자간 템플릿, 더 긴 참여에 대한 다양한 증분 풀 요청 와 보험에 가입된 다리.

이번 감사에서 우리는 새로운 거버넌스 제안 계약, UMA 생태계를 여러 체인으로 확장하는 메커니즘, 오프체인 사양에 따라 ERC721 토큰 보유자에게 보상을 분배하는 메커니즘, WETH를 지원하기 위한 보험 브리지 업데이트를 검토했습니다. 낙관주의 사슬에 있습니다.

감사된 커밋은 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc 범위에는 다음과 같은 계약이 포함됩니다.

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (테스트 및 다각형 계약 제외)
• financial-templates/optimistic-rewarder/* (테스트 계약 제외)

우리는 또한 솔리디티 파일의 변경 사항을 검토했습니다. 풀 리퀘스트 3611.

모든 외부 코드 및 계약 종속성은 문서화된 대로 작동하는 것으로 가정했습니다.

시스템 개요

현재 Governance 계약을 통해 Risk Labs Foundation은 UMA 토큰 보유자가 승인할 수 있는 새로운 거버넌스 조치를 제안할 수 있습니다. 새로운 Proposer 계약은 제안자 역할을 맡아 제안이 실패할 경우 희생될 채권을 제공하는 한 누구나 새로운 제안을 할 수 있도록 하기 위한 것입니다. 제안을 하는 데에는 특별한 인센티브가 없습니다. 그 의도는 받아들여질 가능성이 매우 높은 조치만 제안되도록 하는 것입니다.

새로운 크로스체인 메커니즘을 통해 거버넌스 제안이 이더리움 메인넷에서 Optimism 및 Arbitrum 체인으로 전달될 수 있습니다. 이러한 방식으로 레이어 1의 UMA 거버넌스 메커니즘을 사용하여 지원되는 레이어 2 체인의 UMA 계약을 관리할 수 있습니다. 또한 이 메커니즘을 통해 가격 요청 및 해결 방법이 레이어 간에 전달될 수 있으므로 레이어 2 낙관적 오라클이 DVM에 의해 보호되는 것과 동일한 방식으로 레이어 1 체인의 낙관적 오라클이 메인넷 데이터 검증 메커니즘에 의해 보호될 수 있습니다.

이러한 메시지는 기본 브리지 메커니즘을 사용하여 전송된다는 점은 주목할 가치가 있습니다. 즉, 관련 레이어 2 체인의 특성에 의해 제한된다는 의미입니다. 특히, 레이어 2에서 레이어 1로의 메시지가 브리지를 전송하는 데 일주일 이상이 걸릴 수 있습니다. 또한 UMA 거버넌스 메커니즘은 여러 개의 주문된 트랜잭션을 포함하는 제안을 지원하지만 브리지에 추가할 수 있는 순서만 제한합니다. 이러한 트랜잭션 중 일부는 레이어 2에서 다른 순서로 실행되거나 전혀 실행되지 않을 수 있습니다.

Optimistic Rewarder 계약은 요청하는 모든 사람에게 ERC721 토큰을 발행합니다. 또한 누구나 임의의 데이터를 토큰과 연관시킬 수 있고 다양한 ERC20 토큰을 예치하여 보상으로 배포할 수 있습니다. 임의 데이터의 해석과 토큰 보유자 간의 예상 보상 분배는 지정되지 않은 오프체인 절차를 사용하여 결정됩니다. 누구든지 채권을 예치하려는 경우 특정 ERC721 토큰이 일련의 보상을 받아야 한다고 주장할 수 있습니다. 표준 Optimistic Oracle 메커니즘은 다른 사람이 DVM에 의해 해결될 청구에 대해 이의를 제기할 수 있도록 하는 데 사용됩니다. 시간 내에 분쟁이 발생하지 않는 청구는 유효한 것으로 간주되며 계약은 그에 따라 보상을 분배합니다. (회계를 단순화하기 위한) 유일한 제한은 오라클 채권 토큰을 보상 토큰으로 사용할 수 없다는 것입니다.

마지막으로 PR3611은 지원되지 않는 Optimism 토큰 브리지를 통해 WETH를 보내는 것을 방지하기 위해 보험 브리지 메커니즘을 수정합니다. 대신 Optimism 입금 상자에 예치된 모든 L2 WETH는 브리지를 전송하기 전에 L2 ETH로 포장이 풀립니다. 레이어 1에서는 ETH가 WETH 브리지 풀로 전달되기 전에 WETH로 변환됩니다.

심각한 심각도

[C01] 잘못된 보상에 대해 이의를 제기할 수 없습니다.

보상 요청에 대해 이의를 제기할 때, OptimisticRewardBase 먼저 계약하다 제안을 촉발하다 를 시청하여 이에 대해 더 많은 정보를 얻을 수 있습니다. SkinnyOptimisticOracle 그리고 그 제안에 이의를 제기하다. 그러나 제안은 만료 시간을 설정합니다 현재 (분쟁) 시간으로부터의 오프셋으로, 분쟁은 만료를 지정합니다 원래 보상 요청 시점으로부터의 오프셋으로. 대부분의 경우 이러한 불일치로 인해 오라클은 논쟁의 여지가 있는 제안을 식별하지 못하게 됩니다. 즉, 유효한 분쟁은 처리되지 않고 유효하지 않은 보상 요청은 수락된다는 의미입니다.

이의를 제기할 제안을 올바르게 지정하려면 이의 제기 호출을 업데이트하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 9e15557 in PR3690.

[C02] 제안을 반복적으로 해결

XNUMXD덴탈의 resolveProposal 기능 Proposer 계약 단순히 검증 오라클이 해결했지만 채권이 배포되었는지 확인하지 않습니다. 이는 동일한 제안이 여러 번 해결되어 채권이 중복 지급될 수 있음을 의미합니다. 기존 제안이 해결되면 신고하거나 삭제하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 b152718 in PR3689.

높은 심각도

없음.

중간 정도

[M01] 잘못된 이벤트 매개변수

XNUMXD덴탈의 OptimisticRewarderBase 계약은 다음을 정의합니다. Requested event 에서 방출되는 것 requestRedemption 상환이 요청될 때 기능합니다. 이 이벤트는 상환 만료 시간 마지막 매개변수로. 하지만, 이벤트가 발생하면, 마지막 매개변수가 다음으로 잘못 설정되었습니다. 현재 시간.

마찬가지로 Redeemed event 레코드가 삭제된 후 만료 시간을 읽으므로 0으로 잘못 설정됩니다.

이 이벤트가 오프체인 계산을 트리거하는 데 사용될 수 있다는 점을 고려하면 방출된 값을 적절하게 업데이트하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 f04eef9 in PR3694.

낮은 심각도

[L01] 환매 이의 제기 후 이벤트 발생 부족

XNUMXD덴탈의 OptimisticRewarderBase 계약은 다음을 정의합니다. Disputed event 환매에 대해 이의가 있는 경우 실행되도록 의도된 것입니다. 그러나 이 이벤트는 내부 또는 외부에서 발생하지 않습니다. OptimisticRewarderBase 계약.

민감한 변경 사항이 발생한 후에는 이벤트를 내보내는 것을 고려하세요. dispute 기능, 계약 활동에 따라 오프체인 클라이언트를 추적하고 알리는 것을 용이하게 합니다.

업데이트 : 커밋으로 수정됨 c275e92 in PR3695.

[L02] 불일치 재진입 가드

XNUMXD덴탈의 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을 호출하려면 OptimisticRewarderBase 계약 토큰 허용량을 부여합니다., 그래서 채권 지불을 가져올 수 있습니다. 제안이 실패할 경우, 보상 교환이 취소되었습니다 단, 수당은 초기화되지 않습니다. 따라서 Optimistic Oracle은 다음에 분쟁이 발생할 때까지 불필요한 잔여 수당을 유지합니다. 제안이 실패할 경우 수당을 취소하는 것을 고려하세요.

업데이트 : 커밋으로 수정됨 c2d444b in PR3698.

[L07] 잘못된 환불 주소

환불 L2 주소 Arbitrum_ParentMessenger 초기화되었습니다 L1 거버너가 되어야 하는 계약 소유자에게. 마찬가지로, setRefundL2Address 댓글이 있습니다 주지사에게 설정해야한다고 말합니다. 그러나 브리지를 통해 메시지를 전달할 때 이 값은 L2 사용자로 설정, 이는 티켓이 해결된 후 초과 자금을 받는 Arbitrum의 주소입니다. L1 거버너 주소는 Arbitrum에서 액세스할 수 없으므로 이 주소로 보낸 모든 자금은 손실됩니다.

유효한 L2 주소로 설정하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 b3f2dd1 in PR3687.

[L08] 아동 메신저를 변경하는 메커니즘

XNUMXD덴탈의 GovernorSpoke 와 OracleSpoke 각각의 계약은 업데이트할 메커니즘 없이 생성자에서 하위 메신저를 초기화합니다. 이는 다음을 의미합니다. 어린이 메신저가 변경되었습니다, 두 스포크 계약 모두 더 이상 사용되지 않습니다.

스포크 계약은 메신저보다 더 안정적일 가능성이 높으므로 스포크에 메신저를 업데이트하는 메커니즘을 포함하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 7c9e061 in PR3688.

참고 및 추가 정보

[N01] 채권토큰 변경

XNUMXD덴탈의 Proposer 계약에는 다음이 포함됩니다 메커니즘 소유자가 제안 채권의 규모를 변경할 수 있습니다. 채권 토큰도 변경할 수 있는지 여부를 고려하세요. 이를 위해서는 기존 제안이 해결될 때 올바른 채권 통화를 식별하는 메커니즘이 필요합니다.

업데이트 : 별일 아니다. 이 문제에 대한 UMA의 성명:

N01은 제안자 계약을 활성화하여 채권 토큰을 UMA가 아닌 다른 것으로 변경할 것을 권장합니다. 우리는 이 기능에 대해 $UMA 이외의 다른 토큰을 지원할 의도가 없으므로 이 문제에 대해 어떠한 변경도 하지 않기로 결정했습니다. 게다가 계약당 단일 토큰은 이 논리를 최대한 단순하게 유지합니다. 마지막으로 변경이 필요한 경우(예: 토큰 마이그레이션의 경우) 다른 토큰과 함께 새로운 제안자 계약을 배포하고 해당 토큰을 사용하도록 시스템을 마이그레이션하는 제안을 시작할 수 있습니다.

[N02] 불완전한 인터페이스

XNUMXD덴탈의 ChildMessengerInterface 지정하지 않습니다 processMessageFromCrossChainParent 기능은 부모 메신저에 의해 존재한다고 가정하더라도 마찬가지입니다. 완전성을 위해 포함하는 것을 고려하세요.

업데이트 : 고정되지 않았습니다. 이 문제에 대한 UMA의 성명:

다른 체인의 메시지를 처리하기 위한 Polygon의 메서드에는 _processMessageFromRoot라는 내부 메서드가 호출되는 다소 사용자 지정 논리가 필요하기 때문에 ChildMessengerInterface 내에서 이를 구현하면 Polygon_ChildMessenger와의 호환성이 손상되므로 이 인터페이스를 일관성 없는 상태로 두기로 선택했습니다.

[N03] 잘못된 인터페이스

XNUMXD덴탈의 GovernorSpoke 잘못 계약하다 를 사용하여 ChildMessengerConsumerInterface 유형 그것을 설명하기 위해 messenger 변하기 쉬운. 다음을 사용하는 것을 고려해보세요. ChildMessengerInterface 대신.

업데이트 : 커밋으로 수정됨 f31a527 in PR3680.

[N04] 토큰을 당겨서 저장하세요

안에 이전 감사 우리는 그 목적에 대해 의문을 제기했습니다. Store 계약의 payOracleFeesErc20 기능 (문제 L19). UMA 팀 기능을 유지하기로 결정했습니다 잠재적인 향후 수정을 위해 인터페이스를 표준화합니다. 함수의 목적이 완전히 명시되지 않았기 때문에, 다음과 같은 경우에 트리거되어야 하는지 여부가 불분명합니다. Proposer 계약 채권을 압수하다. 다음과 같은 경우에 사용해야 할 것 같습니다. OracleHub 가격 요청에 대한 비용을 지불합니다. 어느 시나리오에서든 함수를 사용해야 하는지 여부를 고려하세요.

업데이트 : 확인되었습니다. 이 문제에 대한 UMA의 성명:

N04는 Store 사용과 일치하도록 Proposer 및 OracleHub 계약 모두에서 수수료를 지불하기 위해 Store의 payOracleFeeErc20 방법을 사용할 것을 권장합니다. 우리는 이 기능을 사용하지 않기로 결정했습니다. 이는 추가 인터페이스(상점용)를 가져와야 하고 채권 금액을 FixPoint로 캐스팅해야 함(추가 가져오기도 필요함)을 의미하기 때문입니다. 코드를 단순하고 깔끔하게 유지하려면 20년 1월 2020단계 감사에서 payOracleFeeErcXNUMX에 대한 OZ 피드백은 이 방법이 실제로 유용하지 않아 이러한 종류의 통합을 추론하기가 더 어렵다는 것이 타당했습니다.

[N05] 코드의 TODO

프로젝트의 이슈 백로그에서 추적해야 하는 "TODO" 주석이 코드 베이스에 있습니다. 예를 들어:

• 라인 37 of Arbitrum_ParentMessenger 계약
• 라인 25 of Optimism_ChildMessenger 계약
• 선 83 와 146 of OracleHub 계약.

개발 중에 “TODO” 주석을 잘 설명하면 추적하고 해결하는 과정이 더 쉬워집니다. 해당 정보가 없으면 이러한 주석은 부패하는 경향이 있으며 시스템 보안에 대한 중요한 정보는 프로덕션에 릴리스될 때 잊어버릴 수 있습니다.

이러한 TODO 주석에는 수행 대기 중인 작업에 대한 간략한 설명과 프로젝트 저장소의 해당 문제에 대한 링크가 포함되어야 합니다.

이 정보를 추가하려면 TODO 주석을 업데이트하는 것이 좋습니다. 완전성과 추적성을 위해 서명과 타임스탬프를 추가할 수 있습니다. 예를 들어:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

업데이트 : 커밋으로 수정됨 5d57b5b in PR3684.

[N06] 오타

코드베이스에는 다음과 같은 인쇄상의 오류가 포함되어 있습니다:

• . Admin_ChildMessenger 계약, impleenting 되어야 implementing
• . OptimisticRewarderBase 계약, timestap 되어야 timestamp.
• . OptimisticRewarderBase 계약, liveness liveness 되어야 liveness.
• . GovernorSpoke 계약, only called 되어야 only be called.
• . Optimism_ChildMessenger 계약:

업데이트 : 커밋으로 수정됨 9b92b0b in PR3681.

[N07] 미사용 수입품

코드의 가독성을 높이려면 사용하지 않는 다음 가져오기를 제거하는 것이 좋습니다.

업데이트 : 커밋으로 수정됨 40b7221 in PR3682.

[N08] L2 트랜잭션 주문

XNUMXD덴탈의 Governor 보장 제안서 내의 거래는 순서대로 실행됩니다. 그러나 해당 거래에 크로스체인 거래가 포함된 경우 이는 올바른 순서로 L1 브리지 계약에 도달한다는 것을 보장할 뿐입니다. Arbitrum의 경우 L2에서 마무리되기 전에 재정렬될 수 있습니다. 따라서 거버넌스 제안은 재정렬된 L2 트랜잭션의 가능성을 허용하도록 구성되어야 합니다.

업데이트 : 커밋으로 수정됨 0fb2e7b in PR3703. 그만큼 GovernorHub 이제 L2 트랜잭션 배열을 중계할 수 있습니다.

결론

코드베이스에서 두 가지 중요한 문제가 발견되었습니다. 심각도가 중간인 문제 하나와 사소한 취약점 여러 개가 발견되었으며 수정을 위한 권장 사항이 제안되었습니다.

출처 : https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6