2021 년 12 월 1 일
UMA 사용자가 이더리움 블록체인에서 신뢰가 최소화된 금융 계약을 체결할 수 있는 플랫폼입니다. 우리는 이전에 감사했습니다 분산형 오라클, 특정 금융 계약 템플릿, 일부 임시 풀 요청, 영구 다자간 템플릿 및 더 긴 참여에 대한 다양한 증분 풀 요청. 이 감사에서 우리는 레이어 2 체인에서 이더리움 메인넷으로 토큰을 빠르게 보내는 새로운 메커니즘과 Optimistic Oracle에 대한 관련 변경 사항을 검토했습니다. 검토는 2주에 걸쳐 3명의 감사자가 완료했습니다.
범위
감사된 커밋은 f24ad501c8e813cf685f72217e7f13c8f3c366df
범위에는 다음과 같은 계약이 포함됩니다.
- Contracts/insured-bridge/* (테스트 계약 제외)
- Contracts-ovm/insured-bridge/implementation/*
- 계약/공통/구현/AncillaryData.sol
- Contracts/oracle/implementation/SkinnyOptimisticOracle.sol
우리는 또한 솔리디티 파일의 변경 사항을 검토했습니다. 풀 리퀘스트 3445.
모든 외부 코드 및 계약 종속성은 문서화된 대로 작동하는 것으로 가정했습니다.
시스템 개요
지원되는 레이어 2(L2) 체인인 Optimism 및 Arbitrum은 이더리움 메인넷(L1)으로 자금을 이체하는 메커니즘을 제공합니다. 그러나 보안상의 이유로 이러한 전송이 완료되기까지 상당한 지연이 있습니다. 이 문제를 해결하기 위해 L2 토큰 소유자는 토큰이 결국 L1 UMA 계약인 Bridge Pool에 (일괄로) 전송될 것임을 알고 UMA 계약인 Deposit Box에 자금을 예치할 수 있습니다. 전송할 토큰마다 별도의 Bridge Pool이 있습니다.
L2 입금 후, 누구든지 세부 정보를 L1 Bridge Pool에 중계할 수 있으며, 누군가 중계된 정보에 이의를 제기하려는 경우를 위해 잠시 대기합니다. 모든 분쟁은 Skinny Optimistic Oracle에서 처리합니다(아래 설명 참조). 중계를 수락하기 전에 유동성 공급자는 LP 토큰과 교환하여 Bridge Pool 계약에 사전 자금을 조달해야 합니다. 논쟁의 여지가 없는 중계는 유효한 것으로 간주되며 Bridge Pool은 자체 준비금을 사용하여 전송을 완료합니다. 여기서 전송의 일부는 중계자에게 전용되고 일부는 유동성 수수료로 유지됩니다. 자금은 L2 입금이 완료되고 유동성 수수료가 LP 토큰 보유자에게 할당되면 결국 보충됩니다.
Bridge Pool은 또한 분쟁 기간이 만료되기 전에 이체 금액의 일부와 교환하여 누구나 개별적으로 이체에 자금을 조달할 수 있습니다(Bridge Pool 준비금 없이). 릴레이는 여전히 이의를 제기할 수 있으므로 릴레이가 잘못된 것으로 간주되면 이 자금이 손실됩니다. 대부분의 경우 이 메커니즘을 통해 사용자는 즉각적인 L2-L1 토큰 전송을 경험할 수 있습니다.
Skinny Optimistic Oracle은 개념적으로 기존 Optimistic Oracle과 매우 유사합니다. 그것은 사용자가 오라클 요청의 결과를 단순히 주장할 수 있는 인센티브 메커니즘을 제공하며, 이는 논쟁의 여지가 없으면 정확하다고 가정합니다. 분쟁은 이전 감사 보고서에 설명된 더 느린 DVM 메커니즘으로 분류됩니다. 주요 차이점은 새 버전에서는 사용자가 함수 호출을 실행할 때 모든 관련 정보를 제공해야 하므로 값을 저장하거나 저장소에서 검색할 필요가 없다는 것입니다. 또한 요청자가 활성 요청에서 구성 매개변수를 변경할 수 있는 기능을 제거합니다.
우리는 이전에 다양한 금융 상품을 생성하기 위한 일반적인 메커니즘을 제공하는 장단기 계약을 검토했습니다. 이러한 계약은 만료 시간에 도달하고 결제 가격을 알면 해결될 수 있습니다. Pull Request 3445에 의해 도입된 변경 사항은 만료 시간 이전에 결제 가격을 알면 계약을 조기에 해결할 수 있는 가능성을 도입합니다.
권한있는 역할
L2 예금 상자에는 지원되는 토큰과 브리지를 통해 L1으로 일괄 처리된 토큰을 보내기 위한 최대 속도를 비롯한 여러 구성 매개변수가 있습니다. 또한 L1 토큰 계약, L2 토큰 계약 및 해당 브리지 풀 간의 일관성을 보장하도록 구성해야 합니다. 이러한 매개변수는 L1의 관리자 계약에 의해 설정되며, 이는 브리지 풀의 분쟁 해결 프로세스도 매개변수화합니다. 계약은 UMA 거버넌스 메커니즘에 의해 제어될 것으로 예상되므로 사용자는 이 프로세스를 신뢰하여 시스템을 현명하고 공정하게 관리해야 합니다.
생태계 종속성
검토된 모든 구성 요소는 시간 기반 논리를 사용하므로 이더리움 가용성에 의존합니다. 특히 분쟁 거래가 크게 지연되는 경우 무효 중계 또는 가격 제안이 잘못 확인될 수 있습니다.
또한 토큰 브리지는 L2 예금 상자로 전송된 모든 자금이 결국 해당 L1 브리지 풀로 전송될 것이라고 암시적으로 가정합니다. 이는 Optimism 및 Arbitrum 브리지의 정확하고 지속적인 기능과 해당 분쟁 해결 메커니즘에 달려 있습니다.
마지막으로 L2 보관함으로 보내진 토큰은 받는 사람이 아닌 L1의 브리지 풀에 할당됩니다. 풀에서 자금을 회수하려면 L1 토큰 보유자가 먼저 추가 토큰과 일치시켜야 합니다. 따라서 메커니즘은 항상 유동성을 보장하기 위해 충분히 깊은 L1 토큰 시장에 의존합니다.
고객이 보고한 문제
감사 중에 UMA 팀은 강조할 가치가 있는 여러 문제와 행동을 독립적으로 식별했습니다.
Optimistic Oracle 또는 Bridge Admin 매개변수가 릴레이의 챌린지 기간 동안 변경되는 경우 릴레이에 이의를 제기하면 제안자나 이의 제기자에 대한 추가 소구 없이 릴레이가 삭제됩니다. 예를 들어, 담보 토큰을 위해 릴레이가 전송되었다고 상상해보십시오.
TOKEN_A
, 하지만 릴레이 중간에TOKEN_A
담보 화이트리스트에서 제거됩니다. 화이트리스트에 없는 담보물에 대해 OO 또는 DVM에 가격 요청을 제출할 수 없기 때문에 이제 분쟁이 되돌릴 것입니다. 유효한 이의 제기 요청을 차단하고 싶지 않으므로BridgePool
에 대한 보류 중인 릴레이를 삭제합니다.TOKEN_A
분쟁의 경우. 이 설계 결정의 결과는 다음과 같습니다.
1. 최종 수수료 인상은 다음을 야기합니다. 해당 토큰에 대한 미결제 릴레이는 옳고 그름에 대한 분쟁을 통해 "취소 가능"합니다. 취소는 어느 당사자에게도 이익이 되지 않으므로 최종 수수료 변경 실행 중에 존재하게 되는 (드문) 잘못된 요청을 기꺼이 죽일 정직한 이의 제기자가 있다고 가정합니다. 이것은 또한 그리퍼가 릴레이를 취소하고 강제로 다시 릴레이하기 위해 가스를 소비할 수 있음을 의미합니다.
2. 식별자 또는 토큰의 화이트리스트 해제(무슨 문제가 발생하지 않는 한 발생해서는 안 됨)는 다음을 유발합니다.
3. 모든 요청이 취소될 수 있고 분쟁에 대한 경제적 인센티브가 없는 경우, 논쟁의 여지가 없는 요청의 연장된 기간. 이것은 분쟁을 완전히 차단하는 대안보다 나은 것처럼 보이지만, 그리퍼는 가스를 지불하여 릴레이를 무기한 차단하거나 벌칙(가스 요금 제외) 없이 불량 릴레이를 보낼 수 있기 때문에 확실히 매우 나쁩니다.참고: 이것은 최종 수수료 또는 담보 화이트리스트와 같은 매개변수를 한동안 "고정"하는 OO에 대한 대안이지만, 이는 OO에 대한 추가 호출이 필요하며 이는 행복한 경로에 비용이 많이 듭니다.
릴레이를 통해 속도를 높일 수 있습니다.
speedUpRelay()
그들이 생존을 통과한 후. 이것에 대한 위험은 보이지 않지만 플래시 대출 + 속도 향상 + 활성 후 정산 가능성을 열어 플래시 차용자에게 "무료"에 대한 즉각적인 중계 수수료를 제공합니다. 우리는이 제안에서 이것을 방지 PR.
On
settle
,BridgePool
하는WETH
풀이고 수신자는 다음이 아닌 계약입니다.payable
(ETH를 받을 수 없음), 그런 다음settle
실패합니다. 이 문제를 수정하고 전송 시 대체할 계획입니다.WETH
, 그러나 아직 이에 대해 수행된 뛰어난 작업은 없습니다.
In
relayDeposit
, 우리는 확인BridgePool
님의 잔액이 중계할 금액과 제안자 보증금을 더한 금액보다 많습니다. 제안자 채권이 수표 후 사용자로부터 인출되기 때문에 이것은 구식 수표이며 너무 보수적입니다. 우리는 이 제안된 PR.
방금 버그를 잡았습니다.
chainId
inBridgePool
, 의 일부로 포함Deposit
struct 및 모든 릴레이 관련 기능에 대한 기능 입력(예:relayDeposit
,speedUpRelay
,settle
) 유형uint8
. 예를 들어 ID가 421611인 Arbitrum을 처리하기에는 너무 작은 유형입니다. 실제로 이 버그를 잡아 L2 쪽에서 수정했습니다.BridgeDeposit
설정했습니다chainId
입력uint256
. 이 PR은chainId
onBridgePool
유형 일치BridgeDepositBox
: UMA 프로토콜/프로토콜#3463
이전에는 분쟁 기능이 예금 금액을 공제하지 않았습니다.
pendingReserves
(이것은 아직 정산되지 않은 릴레이로 인해 예비 풀이 얼마나 잠겨 있는지를 추적하는 변수입니다). 결과는 각 분쟁이 풀의 릴레이 금액을 무기한으로 잠그는 것이었습니다. LP에서 철회하거나 향후 릴레이에서 사용할 수 없습니다. 수정 사항은 다음과 같습니다. UMA 프로토콜/프로토콜#3473.
버그를 발견했습니다.
BridgeDepositBox
어디에hasEnoughTimeElapsedToBridge
여부를 확인하지 않습니다uint256
값은 다음과 같습니다.0
기본적으로: PR 3484에서 수정됨
브릿지 풀 컨트랙트의 addLiquidity 메소드에서 전송되는 토큰과 발행되는 LP 토큰 사이에 환율 메소드(상태 수정)가 호출됩니다. 이 계산은 메서드의 맨 위로 이동해야 합니다. 이로 인해 매우 이상한 상태 값이 발생합니다. 홍보 참조 여기에서 지금 확인해 보세요. 고치다.
보기 방법
liquidityUtilizationPostRelay
(오프체인에서만 사용됨) 잘못된 사용률을 보고합니다. 에 분모 이 줄 그냥해서는 안됩니다liquidReserves
, 대신 사용되지 않고 활용된 매장량을 나타내야 합니다. 결정된 여기에서 지금 확인해 보세요..
업데이트
문제 수정 외에도 다음과 같은 점진적 변경 사항도 검토했습니다.
- PR3500 중복 토큰 매개변수를 제거합니다.
BridgePool
이벤트. - PR3478 로컬로 캐시된 변수 목록에 DVM 최종 수수료를 추가합니다.
- PR3460 잠재적인 부정적인 유동성 활용 엣지 케이스를 설명합니다(N04를 해결하는 것 외에도).
- PR3482 중복 파일을 제거하고 OVM 2.0 변경 사항에 따라 OVM 상수를 업데이트합니다.
- PR3585 업데이트
BridgeDepositBox
일관성을 위한 인터페이스 및 OpenZeppelin 사용SafeERC20
도서관.
수정 사항을 검토하는 동안 또 다른 문제를 확인했습니다. 의 가치를 결정할 때 BridgePool
LP 토큰이 있습니다. 예기치 않게 음수 오버플로가 발생할 수 있는 중간 계산, 유동성 추가 및 제거를 일시적으로 비활성화합니다. 미분배 수수료를 빼기 전에 사용된 준비금을 더하기 위해 계산을 재정렬해야 합니다.
심각한 심각도
[C01] 갇힌 제안자 보상
XNUMXD덴탈의 LongShortPair
계약 제안자 보상을 검색합니다. 어느 주소에서든 만료를 트리거하며 Optimistic Oracle에서 가격 제안을 장려하는 데 사용됩니다. 그러나, 그 LongShortPairCreator
계약도 자금을 검색하고 전달합니다. 배포자 주소에서. 이러한 추가 자금은 Optimistic Oracle에 전달되지 않고 대신 LongShortPair
계약.
중복 전송 제거를 고려하십시오.
업데이트 : 커밋으로 수정됨 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
높은 심각도
[H01] 동시 릴레이 고갈 예비
XNUMXD덴탈의 relayDeposit
기능 BridgePool
계약 계약에 충분한 자금이 있는지 확인 전송을 실행합니다. 다만, 이에 해당하지 않는다. 보류 준비금, 활성 릴레이에 할당된 자금을 추적합니다. 따라서 여러 동시 릴레이가 동일한 자금에 의존할 수 있으며 모두 즉시 결제할 수 있는 것은 아닙니다. 특히, 안정적인 전송 흐름으로 즉각적인 중계자 반환이 무기한 지연될 수 있습니다.
보류 중인 매장량이 액체 매장량을 초과하도록 하는 릴레이 방지를 고려하십시오.
업데이트 : 커밋으로 수정됨 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] 브리징 매개변수 경계가 일치하지 않습니다.
XNUMXD덴탈의 deposit
기능 의 BridgeDepositBox
레이어 2 체인에 배포된 계약은 L2와 L1 사이의 자금을 연결하는 데 사용됩니다. 특히 중계자에게 인센티브를 제공합니다. 계전기 연결된 L1에 대한 거래 세부 정보 BridgePool
. 단, 금고는 포함 범위 브리지 풀이 사용하는 동안 중계 수수료를 제한하기 위해 배타적 경계. 즉, 일부 예치금(25% 중계 수수료 포함)은 중계할 수 없으며 자금은 두 계층 모두에서 액세스할 수 없습니다.
모든 유효한 예금이 중계될 수 있도록 두 계층에서 검증을 동기화하는 것을 고려하십시오.
업데이트 : 커밋에서 수정됨 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. 이것은 원래 Critical 심각도로 분류되었지만 UMA 팀이 자금이 엄격하게 갇혀 있지 않고 DVM 유권자가 영향을 받는 예금에 대한 수정된 릴레이 설명을 수락하는 데 동의하면 해제될 수 있다고 지적하면서 하향 조정되었습니다.
중간 정도
[M01] 잘못된 주소로의 콜백
XNUMXD덴탈의 SkinnyOptimisticOracle
가격 요청자가 있는 경우 콜백 함수를 호출하여 요청자가 중요한 상태 변경에 응답할 수 있습니다. 그러나 콜백은 가격 요청자 대신 가격 제안자에서 잘못 호출됩니다. 전에, proposePriceFor
기능. 이는 가격 요청자가 가격 제안에 응답할 수 없음을 의미합니다.
다행히 이 기능은 현재 코드 기반에서 사용되지 않습니다. 그럼에도 불구하고 priceProposed
요청자에 대한 콜백.
업데이트 : 커밋 시 수정됨 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] 잘못된 추가 기능
XNUMXD덴탈의 appendKeyValueBytes32
기능 입력을 형식화된 형식으로 결합해야 합니다. bytes
정렬. 그러나, 그 currentAncillaryData
is 잘못 폐기.
보조 데이터부터 오라클 해결 프로세스에 영향을 미칩니다., 잘못된 값은 Oracle 결과를 손상시킬 수 있습니다. 다행히 전화 한 통 appendKeyValueBytes32
코드베이스에서 빈을 사용합니다. currentAncillaryData
버퍼이므로 버그는 이 경우에 영향을 미치지 않습니다.
업데이트 고려 appendKeyValueBytes32
기능을 currentAncillaryData
반환된 바이트열 배열에 포함됩니다.
업데이트 : 커밋에서 수정됨 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] 불완전한 보조 데이터 검증
XNUMXD덴탈의 LongShortPair
건설자 확인합니다 customAncillaryData
충분히 작은. 다만, 이에 해당하지 않는다. 조기 만료 필드. 이는 낙관적 오라클을 의미합니다. 예기치 않게 거부할 수 있습니다 이 기능을 비활성화하는 조기 만료 가격 요청.
추가 필드를 고려하여 유효성 검사를 업데이트하는 것이 좋습니다.
업데이트 : 커밋으로 수정됨 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] 잘못 처리된 XNUMX 타임스탬프
. LongShortPair
계약, XNUMX 조기 만료 타임스탬프는 깃발로 사용 아무도 조기 만료 메커니즘을 트리거하지 않았음을 나타냅니다. 그러나 그 메커니즘을 발동 제로 타임 스탬프로. 이 시나리오에서는 Optimistic Oracle이 호출되지만 후속 가격 요청에 대한 보호 효과가 없을 것입니다. 다행히 한번 정산 가격이 선택됨, 재정의되지 않으므로 불일치 정산으로 이어지지 않습니다. 그럼에도 불구하고 후속 가격 요청은 기록된 조기 만료 타임스탬프 변경, 정산 가격을 결정하는 데 XNUMX 타임스탬프가 사용된 경우에도 마찬가지입니다. 그것은 또한 수 오해의 소지가 있는 사건을 일으키다.
제로 타임스탬프를 사용하여 조기 만료를 방지하는 것이 좋습니다.
업데이트 : 커밋으로 수정됨 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] 제로 본드 가능
XNUMXD덴탈의 requestPrice
기능 SkinnyOptimisticOracle
계약 최종 수수료를 채권으로 사용 채권이 지정되지 않은 경우. 그러나, 그 requestAndProposePriceFor
기능 제로 본드를 사용할 수 있습니다, 그것의 모순 @notice
및 @param
코멘트. 제로 본드는 유효하지 않은 제안이나 분쟁에 대한 인센티브를 약화시킵니다.
다행히도 이 함수만 호출 코드 베이스에서 제안자 본드를 설정합니다. 그럼에도 불구하고 보증금이 지정되지 않은 경우 최종 수수료를 사용하는 것이 좋습니다.
업데이트 : 커밋으로 수정됨 daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] 불필요한 관리자 권한
XNUMXD덴탈의 BridgePool
계약 ~로부터 상속 받다 ExpandedERC20
유동성 공급자에게 LP 토큰을 발행할 수 있습니다. 이것은 OpenZeppelin의 기능을 상속합니다. ERC20
계약 및 또한 관리자 권한 제공 계약 배포자에게 전달하여 LP 토큰을 발행하고 소각할 수 있습니다. 그러나 이 권한은 필수 사항이 아니며 행사할 경우 유동성 제공자에게 부당한 불이익을 줄 수 있습니다.
수정을 고려해보세요 BridgePool
에서 직접 상속 ERC20
대신 ExpandedERC20
.
업데이트 : 커밋에서 수정됨 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
낮은 심각도
[L01] 만기 시 결제 불가
XNUMXD덴탈의 settle
기능 LongShortPair
계약 정착 조건을 고려 현재 시간이 만료 타임스탬프 이전 또는 이후인 경우. 그러나 현재 시간이 만료 타임스탬프와 일치하면 잘못 되돌립니다.
일치하는 포함 범위를 사용하는 것을 고려하십시오. postExpiration
변화.
업데이트 : 커밋에서 수정됨 f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] require 문에 오류 메시지가 없습니다.
에 require 문이 있습니다. BridgePool
계약 오류 메시지 없이.
모든 require 문에 구체적이고 유익한 오류 메시지를 포함하는 것을 고려하십시오.
업데이트 : 커밋으로 수정됨 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] 독스트링 누락
코드베이스 전체에 걸쳐 몇 가지 인스턴스가 있습니다. 이더리움 자연 사양 누락되었거나 불완전합니다. 예는 다음과 같습니다.
계약의 공개 API의 일부인 모든 기능(및 해당 매개변수)을 철저히 문서화하는 것을 고려하십시오.
업데이트 : 강조 표시된 주석은 커밋에서 수정되었습니다. e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. 나머지 코드 기반에서 NatSpec 완전성을 검증하지 않았습니다.
참고 및 추가 정보
[N01] 호출 반환 값이 확인되지 않음
. deposit
기능 L2의 BridgeDepositBox
계약에 낮은 수준의 호출이 있습니다. l2Token
시 l1Token
is l1Weth
. 이 낮은 수준의 호출은 deposit()
에 속하는 기능 WETH 상호 작용. 이 경우 l2Token
WETH와 똑같이 작동하므로 절대 실패해서는 안 됩니다. 그러나 경우에 l2Token
다르게 동작하고 실패하면 이 하위 수준 호출의 성공 플래그가 확인되지 않으므로 되돌릴 수 없습니다.
모든 저수준 호출의 반환 값을 확인하고 적절하게 대응하는 것을 고려하십시오.
[N02] 이벤트에 인덱싱된 매개변수 부족
이 코드베이스에 정의된 많은 이벤트에는 인덱싱해야 하는 매개변수가 있습니다.
고려 인덱싱 이벤트 매개 변수 특정 이벤트를 검색하고 필터링하는 오프체인 서비스 작업을 방해하지 않도록 합니다.
업데이트 : 커밋에서 부분적으로 수정됨 d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. 그만큼 chainId
매개 변수 WhitelistToken
업데이트되지 않았습니다.
[N03] 암시적 캐스팅 불일치
XNUMXD덴탈의 LongShortPair
일반적으로 계약 타임스탬프를 다음과 같이 처리합니다. uint64
값, 암시적으로 캐스트됩니다. uint256
값 낙관적 오라클에 전달. 그러나, 그 requestTimestamp
매개 변수 전에, _requestOraclePrice
기능 에 조기에 캐스팅됩니다. uint256
. 이것은 기능적 결과가 없습니다.
그럼에도 불구하고 일관성을 위해 uint64
이 매개변수에 대해 암시적으로 uint256
Optimistic Oracle에 전달될 때.
업데이트 : 커밋에서 수정됨 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. 이제 타임스탬프가 명시적으로 캐스팅됩니다.
[N04] 잘못된 유형
XNUMXD덴탈의 sendMessage
기능 iOptimism_CrossDomainMessenger
인터페이스 ~을 사용하다 uint256
가스 한도 반면 낙관주의 OVM_CrossDomainEnabled
~을 사용하다 uint32
가스 한도.
일관성과 예측 가능성을 위해 업데이트를 고려하십시오. iOptimisim_CrossDomainMessenger
sendMessage
사용하는 기능 uint32
가스 한도.
업데이트 : 커밋으로 수정됨 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] 검증 부족
의 모든 기능 BridgeAdmin
그 전화 _relayMessage
거래 가치가 일치한다고 가정 l1CallValue
매개변수이지만 적용되지 않습니다.
올바른지 확인 msg.value
설정됩니다.
업데이트 : 커밋으로 수정됨 f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] 가독성
XNUMXD덴탈의 _getDepositHash
기능 의 BridgePool
계약이 풀리다 depositData
구조 l1Token
구성의 인수로 keccak256
와 더불어 abi
부호화. 이것은 작업을 불필요하게 장황하게 만들고 다른 레이어에서 다시 구현할 때 버그로 이어질 수 있습니다.
단순히 순서 쌍이 되도록 인수를 단순화하는 것을 고려하십시오. depositData
및 l1Token
.
업데이트 : 커밋으로 수정됨 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] 재진입 기능
XNUMXD덴탈의 requestAndProposePriceFor
기능 의 SkinnyOptimisticOracle
계약이 신뢰할 수 없는 사람을 호출합니다. msg.sender
그러나 보호받지 못한다. nonReentrant
수정자. 이 경우 보안 문제는 아닌 것 같지만 예기치 않은 동작이 발생할 수 있습니다.
다음을 추가해 보세요. nonReentrant
신뢰할 수 없는 계약을 호출하는 모든 함수에 대한 수정자.
업데이트 : 커밋에서 수정됨 b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
기록되지 않음
XNUMXD덴탈의 relayMessage
기능 의 Arbitrum_Messenger
계약은 민감한 작업을 실행한 후 관련 이벤트를 내보내지 않습니다. 그만큼 relayMessage
서브루틴으로 함수 호출 sentTxToL2NoAliasing
그 자체가 반환 uint256
가치 seqNum
, 그러나 이 반환 값은 relayMessage
기능.
민감한 변경이 발생한 후에 이벤트를 내보내는 것을 고려하여 추적을 용이하게 하고 계약의 활동에 따라 오프체인 클라이언트에 알립니다.
업데이트 : 커밋으로 수정됨 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] 오타
코드베이스에는 다음과 같은 오타가 포함되어 있습니다.
코드 가독성을 높이려면 이러한 오타를 수정하는 것이 좋습니다.
업데이트 : 커밋으로 수정됨 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] 문서화되지 않은 ERC20 승인 요구 사항
XNUMXD덴탈의 requestEarlyExpiration
및 expire
기능 의 LongShortPair
계약은 각각 발신자가 계약에 대한 수당을 부여했다고 가정합니다. 제안자 보상을 당겨.
예측 가능성을 위해 함수 주석에서 이 요구 사항을 문서화하는 것을 고려하십시오.
업데이트 : 커밋에서 수정됨 da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] 미사용 수식어
. BridgePool
계약, onlyFromOptimisticOracle
변화 정의되었지만 코드베이스에서 사용되지 않으므로 제거해야 합니다.
업데이트 : 커밋에서 수정됨 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
결론
2개의 심각한 문제와 1개의 높은 심각도 문제가 발견되었습니다. 모범 사례를 따르고 잠재적인 공격 표면을 줄이기 위해 몇 가지 변경 사항이 제안되었습니다.
- &
- 7
- 계정
- 동작
- 활동적인
- Ad
- 추가
- 주소
- 관리자
- 이점
- All
- 허용
- API를
- 인수
- 회계 감사
- 유효성
- 존재
- BEST
- 모범 사례
- blockchain
- 보물상자
- 다리
- 곤충
- 버그
- 전화
- 가지 경우
- 체포
- 원인
- 도전
- 이전 단계로 돌아가기
- 확인
- 암호
- 댓글
- 구성
- 이 포함되어 있습니다
- 계약
- 계약
- 수
- Current
- 데이터
- 분산 된
- 지연
- 디자인
- 결정
- DID
- 분쟁
- 하지 않습니다
- 초기의
- 간결한
- Edge
- 유효한
- ERC20
- ETH
- 이더리움
- 에테 리움 블록 체인
- 이벤트
- 이벤트
- 예
- 교환
- 기대하는
- 경험
- 특색
- 지우면 좋을거같음 . SM
- 금융
- 먼저,
- 수정
- 플래시
- 따라
- 발견
- 기능
- 기금
- 자금
- 미래
- 가스
- 가스 요금
- 기부
- 통치
- 행복한
- 데
- 여기에서 지금 확인해 보세요.
- 높은
- 강조
- 홀더
- 방법
- HTTPS
- 인센티브
- 포함
- 포함
- 증가
- 정보
- 관심
- 인터페이스
- 문제
- IT
- 알려진
- 리드
- 도서관
- 리퀴드
- 유동성
- 유동성 공급자
- 명부
- 융자
- 장소 상에서
- 고정
- LP
- LP
- 시장
- 경기
- 가장
- 열 수
- 신탁
- 기타
- 플랫폼
- 풀
- 수영장
- 힘
- 방지
- 가격
- 방법
- 신청
- 제공
- 제공
- 공개
- 이유
- 감소
- 보고서
- REST
- 결과
- 반품
- 리뷰
- 위험
- 보안
- 서비스
- 세트
- 정착
- 짧은
- 상당한
- 비슷한
- 작은
- So
- solidity
- 어떤 사람
- 무언가
- 속도
- 지출
- 주 정부
- 성명서
- 저장
- 성공
- 지원
- 표면
- 체계
- test
- 을 통하여
- 도처에
- 시간
- 토큰
- 토큰
- 상단
- 추적
- 거래
- 거래 내역
- 믿어
- 업데이트
- 업데이트
- UPS
- 사용자
- 가치
- 관측
- 허용 된 사이트 목록
- 누구
- 이내
- 없이
- 작업
- 가치
- 제로