스마트 계약에서 저장소 변수를 읽는 방법은 무엇입니까?

Ethereum 스마트 계약의 저장소 레이아웃 이해

1. 이더리움에 배포된 모든 스마트 계약은 각각 32바이트 너비이고 슬롯 0부터 순차적으로 인덱싱되는 영구 저장소 슬롯에서 상태를 유지합니다.

2. 컴파일러는 효율성을 위해 유형 크기 및 패킹 규칙을 고려하여 상태 변수의 선언 순서에 따라 저장 위치를 ​​할당합니다.

3. 구조체, 배열 및 매핑으로 인해 복잡성이 발생합니다. 동적 배열은 슬롯에 길이를 저장하고 keccak256으로 계산된 오프셋에 데이터를 저장합니다. 매핑은 keccak256(키, 슬롯)을 사용하여 저장 위치를 ​​파생합니다.

4. 0.8.0 이전의 Solidity 버전은 가변 경계에 걸쳐 더 엄격한 패킹을 허용한 반면, 최신 버전에서는 더 엄격한 정렬을 적용하여 수동 슬롯 계산 정확도에 영향을 미쳤습니다.

5. 계약 상속은 레이아웃에 영향을 줍니다. 기본 계약의 변수는 낮은 슬롯을 차지하고 선형 순서로 파생 계약의 변수가 그 뒤를 따릅니다.

eth_getStorageAt를 통한 직접 온체인 읽기

1. JSON-RPC 메소드 eth_getStorageAt는 계약 주소, 슬롯 인덱스 및 블록 식별자를 사용하여 특정 스토리지 슬롯에서 원시 32바이트 값을 검색합니다.

2. 슬롯 인덱스는 수동으로 계산하거나 계약의 메타데이터 또는 빌드 정보 파일에 있는 Solidity 생성 스토리지 레이아웃 JSON과 같은 컴파일 아티팩트에서 추출해야 합니다.

3. hardhat-storage-layout 또는 slither-print-storage 와 같은 도구는 AST 및 바이트코드를 구문 분석하여 슬롯 매핑을 자동화하고 인적 오류를 줄입니다.

4. Infura 또는 Alchemy 엔드포인트로 쿼리할 때 속도 제한 및 보관 노드 요구 사항이 적용됩니다. 특히 계약 업그레이드 또는 자체 파괴 전 기록 슬롯 값에 적용됩니다.

5. 16진수로 인코딩된 응답에는 디코딩이 필요합니다. uint256 값은 왼쪽 패딩으로 나타나고 주소는 마지막 20바이트에서 오른쪽 정렬되며 부울은 0x01 또는 0x00에 매핑됩니다.

복잡한 유형을 수동으로 디코딩

1. 정적 배열의 경우 각 요소는 맞을 경우 하나의 슬롯을 차지합니다. 그렇지 않으면 요소가 표준 정렬 규칙에 따라 연속 슬롯으로 쏟아집니다.

2. 동적 배열 데이터는 keccak256(슬롯)에서 시작합니다. 여기서 처음 32바이트는 배열 길이를 보유하고 후속 슬롯은 keccak256(슬롯)+1에서 시작하여 연속적으로 요소를 저장합니다.

3. 매핑에서는 각 키에 대해 keccak256을 다시 계산해야 합니다. 매핑(address => uint256) 공개 잔액 의 경우 주소 0xAbc…의 슬롯은 keccak256(abi.encodePacked(0xAbc..., Slot_index))입니다.

4. 중첩된 구조는 복잡성을 복잡하게 만듭니다. 예를 들어 구조체에 매핑하려면 매핑 슬롯을 먼저 계산한 다음 해당 베이스를 기준으로 구조체 필드 오프셋을 적용해야 합니다.

5. 구조체 내부의 오프셋은 최상위 변수와 동일한 규칙을 따릅니다. uint128 + uint128은 하나의 슬롯에 포함되지만 uint256을 추가하면 정렬 제약으로 인해 새 슬롯이 강제 적용됩니다.

실제 검사에 주조 및 주조 사용

1. 캐스트 스토리지 명령은 계약 주소와 슬롯 번호를 수락하여 ABI 또는 레이아웃이 제공되는 경우 값을 자동으로 가져오고 선택적으로 디코딩합니다.

2. --watch를 사용하면 Cast는 블록 전체의 스토리지 변경 사항을 모니터링하여 재진입 또는 플래시 대출 부작용을 실시간으로 관찰하는 데 유용합니다.

3. Foundry의 Forge Inspection은 변수 이름, 유형, 슬롯 번호 및 바이트 오프셋을 포함한 전체 스토리지 레이아웃을 출력하므로 수동 ABI 구문 분석이 필요하지 않습니다.

4. 소스 코드를 사용할 수 없는 경우 리버스 엔지니어링이 필요합니다. 트랜잭션 추적에서 SSTORE opcode를 분석하면 어떤 슬롯이 언제 작성되었는지 알 수 있습니다.

5. web3.py 또는 ethers.js를 활용하는 사용자 정의 스크립트는 여러 슬롯을 일괄 쿼리하고, 출력을 테이블로 형식화하고, Transparent 또는 UUPS와 같은 알려진 프록시 패턴과 상호 참조할 수 있습니다.

자주 묻는 질문

Q: 소스 코드를 몰라도 컨트랙트에서 스토리지를 읽을 수 있나요? A: 예. 바이트코드 분석, opcode 추적 또는 OpenZeppelin 프록시 또는 ERC-20 밸런스에 대한 일반적인 슬롯 패턴과 같은 경험적 방법을 사용합니다. 그러나 맥락이 없으면 해석이 모호한 상태로 남아 있습니다.

Q: 존재한다고 알고 있는 0이 아닌 값에 대해 eth_getStorageAt가 0을 반환하는 이유는 무엇입니까? A: 가능한 원인으로는 잘못된 슬롯 쿼리, 오래된 블록 번호 사용, 구현으로 전달하지 않고 프록시 대상 지정, 초기화되지 않은 메모리 읽기(기본값은 0) 등이 있습니다.

Q: 오프체인에서 스토리지 읽기를 수행할 때 가스 비용이 발생합니까? A: 아니요. eth_getStorageAt 는 무료 RPC 호출입니다. 가스 비용은 트랜잭션 또는 뷰 기능 내에서 실행되는 온체인 읽기에만 적용됩니다.

Q: 컴파일러 버전 전반에서 스토리지 슬롯 번호에 의존하는 것이 안전합니까? A: 보장되지 않음 - 견고성 업데이트로 인해 레이아웃 알고리즘이 변경될 수 있습니다. 항상 배포 중에 사용된 정확한 컴파일러 버전 및 최적화 설정을 확인하세요.