OP Stack은 공유 계약도 ‘실제 관리자’에게 업그레이드를 요청하게 고쳤다

여러 L2가 일부 인프라 계약을 함께 쓸 때, 업그레이드를 시작한 체인의 관리자가 아닌 그 계약의 진짜 관리자에게 요청하도록 바꿔 업그레이드 실패를 막았다.

프록시(proxy) 계약은 주소와 저장 데이터는 유지한 채 내부 구현만 교체할 수 있다. 누가 교체할지를 통제하는 계약이 ProxyAdmin이다. OP Stack interop 환경에서는 여러 체인이 ETHLockbox·DisputeGameFactory·AnchorStateRegistry·DelayedWETH 같은 일부 계약을 공유할 수 있지만, 각 체인은 서로 다른 ProxyAdmin을 가질 수 있다.

따라서 체인 2에서 업그레이드를 시작하면서 체인 2의 ProxyAdmin으로 공유 계약을 바꾸려 하면, 실제로 체인 1의 ProxyAdmin이 관리하는 그 계약은 권한 검사에서 revert한다. 공유 계약이 어떤 SystemConfig에 연결되어 있는지도 잘못 바꾸면 안 된다.

이번 변경은 무엇인가

Optimism은 2026-07-30 20:21 UTC에 업그레이드 대상이 스스로 보고하는 proxyAdmin()을 먼저 조회하는 _adminFor를 추가했다. 아직 초기화되지 않아 응답하지 못하는 프록시는 기존 default admin을 사용한다. 마찬가지로 systemConfig()를 조회해 공유 계약이 이미 연결된 SystemConfig를 보존한다. regression test는 서로 다른 ProxyAdmin을 가진 두 체인을 migrate한 뒤, 두 번째 체인에서도 공유 계약 업그레이드가 성공하는지 확인한다.

출처: https://github.com/ethereum-optimism/optimism/commit/0ec4c6b759745a33f6f46b67a54a9cdcaebe5312

코드/구조에서는 어떤 차이인가

기존 방식

upgrade(callerChain.proxyAdmin, sharedTarget, newImplementation);
initialize(sharedTarget, callerChain.systemConfig);
// 공유 Target의 실제 관리·설정과 다르면 revert 또는 잘못된 재연결

변경 방식

try target.proxyAdmin() returns (admin) {
    actualAdmin = admin == address(0) ? defaultAdmin : admin;
} catch { actualAdmin = defaultAdmin; }

actualAdmin.upgrade(target, newImplementation);
initialize(target, target.systemConfig() ?? callerDefaultSystemConfig);

왜 이것이 중요한가

업그레이드 권한은 자산·출금·분쟁 해결 계약의 동작을 바꾸는 강력한 권한이다. 이번 수정은 권한을 넓히는 것이 아니라, 이미 각 프록시에 저장된 권한 관계를 정확히 존중한다. 사용자 관점에서는 interop 체인 구성에서 업그레이드가 실패하거나 공유 계약이 다른 체인의 설정을 가리키는 위험을 줄인다.

블록체인 발전 흐름에서의 의미

L2가 단일 체인에서 체인 집합으로 발전하면서, ‘누가 소유하는가’는 계약 주소 하나의 문제가 아니라 공유 자원 그래프의 문제가 된다. 멀티체인 보안은 메시지 검증뿐 아니라 업그레이드 권한과 설정 결속을 보존하는 데 달려 있다.

1차 출처: https://github.com/ethereum-optimism/optimism/commit/0ec4c6b759745a33f6f46b67a54a9cdcaebe5312

Geth는 blob cell 캐시에 데이터가 없으면 blob pool에서 다시 찾는다

캐시에 ‘항목은 있지만 실제 cell 데이터는 없는’ 경우를 성공으로 오해해 빈 데이터를 돌려주던 경로를, 원본 blob pool로 되돌아가 찾도록 고쳤다.