Solidity에서 어레이 스토리지는 어떻게 작동하며 비용은 얼마입니까?

Solidity의 어레이 스토리지 이해

1. Solidity의 배열은 함수 호출 및 트랜잭션 전반에 걸쳐 지속되는 계약 저장소에 저장됩니다. uint[] public value 와 같은 동적 배열이 선언되면 배열에 할당된 슬롯은 배열의 길이만 보유합니다. 실제 데이터 요소는 어레이 슬롯 번호의 keccak256 해시에 저장되므로 안전하고 결정적인 위치 매핑이 가능합니다.

2. 배열의 각 요소는 keccak256(slot) + index 공식에서 파생된 저장소 슬롯에 배치됩니다. 이 메커니즘은 계약에 여러 배열이 존재하더라도 해당 데이터가 충돌하지 않도록 보장합니다. Ethereum 저장소는 256비트로 정렬되어 있으므로 각 슬롯은 하나의 전체 uint256 또는 이와 동등한 크기의 값을 보유할 수 있습니다. 더 큰 유형은 여러 슬롯에 걸쳐 있을 수 있습니다.

3. 고정 크기 배열의 경우 컴파일러는 선언된 변수 위치부터 시작하여 연속적인 저장 슬롯을 예약합니다. uint[3] id 와 같은 고정 배열은 정확히 3개의 인접한 슬롯을 사용합니다. 크기는 컴파일 타임에 알려지기 때문에 길이와 같은 메타데이터는 저장되지 않으므로 액세스가 더 직접적이고 가스 측면에서 약간 더 저렴해집니다.

4. 중첩 배열은 복잡성을 크게 증가시킵니다. 2차원 동적 배열은 동일한 해싱 방법을 사용하여 기본 위치를 계산한 다음 내부 배열 인덱스를 기반으로 오프셋을 적용합니다. 여러 수준의 해싱과 읽기 또는 쓰기 중 SLOAD 작업 증가로 인해 액세스 패턴 비용이 더 높아집니다.

5. 가능한 경우 값을 구조체로 묶거나 더 작은 정수 유형(예: uint256 대신 uint128)을 사용하면 여러 변수를 단일 저장소 슬롯에 넣을 수 있습니다. 이렇게 하면 사용되는 총 슬롯 수가 줄어들고 해당 변수와 관련된 배포 및 상태 수정에 대한 가스 비용이 낮아집니다.

어레이 운영과 관련된 가스 비용

1. push()를 통해 동적 배열에 추가하면 추가된 요소가 0인지 0이 아닌지에 따라 비용이 달라집니다. 저장되는 값이 0이 아닌 경우 이전에 비어 있던 슬롯을 설정할 때 가스 비용이 20,000인 SSTORE 작업이 발생합니다. 슬롯에 이미 데이터가 포함되어 있다고 가정하면 EIP-1283 규칙에 따라 0이 아닌 값을 덮어쓰는 데 5,000 가스가 소요됩니다.

2. 배열에서 요소를 읽으면 SLOAD 작업이 트리거되며 액세스당 가스 비용은 2,100입니다. 각 읽기가 이 기본 비용을 곱하기 때문에 온체인 로직에서는 대규모 배열에 대한 빈번한 반복을 피해야 합니다. 오프체인 인덱싱 서비스는 전체 데이터 세트를 검색하는 데 더 적합합니다.

3. 수동 이동이 구현되지 않는 한 동적 배열에서는 요소 제거가 기본적으로 지원되지 않습니다. pop()을 호출하면 마지막 항목이 제거되고 저장 슬롯을 비울 때 15,000 가스가 환불되므로 사용되지 않은 상태를 정리하는 것이 좋습니다. 그러나 중간에서 항목을 제거하려면 모든 후속 요소를 이동해야 하므로 O(n) 계산이 발생하고 가스 사용량이 높아집니다.

4. 계약 생성 중에 대규모 어레이를 초기화하면 배포 비용이 상당히 증가합니다. 모든 사전 설정된 값은 스토리지 초기화 가스를 소비합니다. 빈 배열을 초기화하고 사용자 상호 작용을 통해 점차적으로 배열을 채워 여러 트랜잭션에 비용을 분산시키는 것이 더 효율적인 경우가 많습니다.

5. 함수 내에서 일시적으로 사용되는 메모리 배열은 영구 저장소에 쓰지 않으므로 SSTORE 비용이 완전히 발생하지 않습니다. 이는 중간 계산에 이상적이지만 트랜잭션 범위를 넘어서는 데이터를 유지할 수 없습니다. 선택적 결과를 스토리지에 쓰기 전에 일괄 처리를 위해 메모리 어레이를 사용하면 전반적인 효율성이 최적화됩니다.

효율적인 어레이 사용을 위한 최적화 기술

1. 키를 통한 무작위 액세스가 필요한 경우 배열보다 매핑을 선호합니다. mapping(uint => address) 와 같은 매핑은 길이를 반복하거나 관리하는 오버헤드 없이 일정한 시간 조회를 제공합니다. 매핑은 또한 인덱스 경계 및 크기 조정에 대한 우려를 없애줍니다.

2. 개별 배열 요소에 대해 삭제를 드물게 사용하십시오. 요소를 수동으로 0으로 설정하는 것이 삭제에 의존하는 것보다 저렴할 수 있으며, 특히 환불이 적용되지 않는 경우 더욱 그렇습니다. 완전한 정리를 위해 배열이 비워질 때까지 pop()을 반복적으로 호출하면 지워진 저장소 슬롯에서 가스 환불이 최대화됩니다.

3. 배열 콘텐츠의 체인 내 노출을 제한합니다. 배열 데이터로 이벤트를 내보내면 외부 시스템이 스토리지에서 직접 읽지 않고도 상태를 재구성할 수 있습니다. 이벤트는 영구 스토리지 쓰기보다 비용이 저렴하고 인덱싱된 매개변수를 통한 필터링을 지원합니다.

4. 추가 작업이 많은 워크로드에 대한 체크포인트 또는 연결 목록 패턴을 구현합니다. 항목 간의 델타 또는 참조만 저장함으로써 계약은 중복되는 데이터 저장 공간을 줄이고 비용이 많이 드는 재구성을 최소화합니다. 이 접근 방식은 기록 상태 또는 사용자 활동 로그를 추적하는 데 적합합니다.

5. 어셈블리 수준 최적화를 신중하게 활용하십시오. 인라인 Yul 코드는 높은 수준의 Solidity 구성보다 더 빠르게 저장 위치를 ​​계산할 수 있지만 주소 지정이 잘못될 위험이 있습니다. 고급 개발자만이 낮은 수준의 저장소 조작을 시도하여 다양한 컴파일러 버전에 걸쳐 철저한 테스트를 수행해야 합니다.

자주 묻는 질문

범위를 벗어난 배열 인덱스에 액세스하면 어떻게 되나요? 현재 배열 길이를 벗어난 인덱스에 액세스하면 유효하지 않은 opcode가 트리거되어 남은 가스를 모두 소모하고 트랜잭션을 되돌립니다. 액세스하기 전에 코드에서 경계 검사를 명시적으로 처리해야 합니다.

배열을 계약 간에 인수로 전달할 수 있나요? 예, 내부 및 외부 함수 호출에서 배열을 전달할 수 있습니다. 호출 데이터 배열은 메모리에 복사되는 것을 방지하므로 대규모 입력에 효율적입니다. 외부 인터페이스에는 정적 및 동적 유형을 모두 지원하는 ABI 인코딩이 필요합니다.

동적 배열이 확장할 수 있는 크기에 제한이 있습니까? 이론적 한계는 사용 가능한 가스 및 블록 크기 한계에 의해 제한됩니다. 실질적인 제약에는 추가 및 반복 비용 증가가 포함됩니다. 지나치게 큰 어레이를 온체인에서 처리할 때 계약은 트랜잭션 가스 한도에 도달할 위험이 있습니다.

빈 배열 선언은 저장 공간을 소비합니까? 초기화하지 않고 배열을 선언하면 길이가 0으로 설정되고 하나의 스토리지 슬롯을 차지합니다. 요소가 추가될 때까지 추가 슬롯이 할당되지 않습니다. 이러한 최소 설치 공간은 초기화되지 않은 배열을 지연된 채우기에 대해 비용 효율적으로 만듭니다.