스마트 계약은 데이터를 어떻게 저장하며, 저장, 메모리, 호출 데이터의 차이점은 무엇입니까?

스마트 계약이 블록체인에 데이터를 저장하는 방법

1. 이더리움과 같은 블록체인 플랫폼의 스마트 계약은 분산 원장을 사용하여 상태 변경을 유지하고 데이터를 영구적으로 저장합니다. 계약 기능이 변수를 수정할 때마다 해당 변경 사항은 네트워크의 모든 노드에 기록됩니다. 이는 투명성과 불변성을 보장합니다. 스마트 계약에 저장된 데이터는 개별 거래 이후에도 지속되며 계약이 존재하는 한 계속 액세스할 수 있습니다.

2. 스마트 계약의 데이터 저장은 계약 수준에서 선언된 변수를 통해 발생합니다. 이러한 변수는 EVM(Ethereum Virtual Machine) 아키텍처의 일부인 '스토리지'에 저장됩니다. 각 계약에는 고유한 전용 저장 공간이 있으며, 이는 가스 비용으로 인해 지속적이고 수정 비용이 많이 듭니다. 트랜잭션이 상태 변수를 업데이트하면 채굴자는 변경 사항을 검증하고 이를 블록체인의 상태 트리에 기록합니다.

3. EVM은 스토리지를 각 슬롯이 32바이트를 보유하는 대규모 키-값 저장소로 취급합니다. 변수는 공간 사용량을 최소화하기 위해 효율적으로 패킹됩니다. 예를 들어, 단일 슬롯 내에 여러 부울 값을 저장할 수 있습니다. 비효율적인 패킹으로 인해 가스 소비가 증가하므로 개발자는 변수 선언 방법에 주의해야 합니다.

4. 스토리지에서 읽고 쓰는 경우 가스 비용이 다릅니다. 쓰기 작업은 읽기보다 비용이 훨씬 더 많이 들고, 0이 아닌 값을 초기화하는 것은 0으로 설정하는 것보다 비용이 더 많이 듭니다. 데이터가 한번 기록되면 완전히 삭제할 수 없습니다. 대신 값을 0으로 설정하면 일부 가스가 환불되므로 개발자가 사용하지 않는 데이터를 정리하도록 장려할 수 있습니다.

저장소, 메모리 및 호출 데이터의 차이점

1. 저장소는 상태 변수가 보관되는 계약과 관련된 영구 데이터 영역을 의미합니다. 이는 함수 호출 및 트랜잭션 전반에 걸쳐 지속됩니다. 함수 외부에서 선언된 모든 변수(예: 단위 잔액 또는 매핑(주소 => bool) 화이트리스트)는 기본적으로 저장소에 상주합니다. 스토리지 액세스는 영속성 및 전역 복제로 인해 느리고 비용이 많이 듭니다.

2. 메모리는 기능 실행 중 데이터를 보관하기 위해 사용되는 임시 공간입니다. 이는 함수 호출이 끝난 후 지워지며 함수 내에서 사용되는 배열 또는 구조체와 같은 지역 변수 및 복합 유형에 이상적입니다. 저장소와 달리 메모리는 액세스 비용이 저렴하지만 호출 간에 데이터를 유지하지 않습니다. 문자열, 동적 배열 및 함수 인수는 달리 명시적으로 할당되지 않는 한 여기에 있는 경우가 많습니다.

3. Calldata는 특히 외부 함수 호출의 경우 함수 인수가 저장되는 특수 읽기 전용 영역입니다. 이는 데이터를 메모리로 복사하는 것을 방지하여 공용 또는 외부 함수에 전달되는 바이트 배열과 같은 대규모 입력에 효율적입니다. calldata는 수정할 수 없기 때문에 실행 중 수정이 필요하지 않은 입력 매개변수에만 적합합니다.

4. 배열, 문자열, 구조체와 같은 참조 유형을 처리할 때는 저장소, 메모리, 호출 데이터 등 Solidity의 위치 키워드를 지정해야 합니다. 잘못 사용하면 불필요한 복사, 가스 요금 증가 또는 런타임 오류가 발생할 수 있습니다. 예를 들어, calldata를 사용하지 않고 큰 배열을 함수에 전달하면 불필요하게 메모리에 로드되어 계산 오버헤드가 증가합니다.

함수 설계에 있어서 데이터 위치의 의미

1. 기능을 설계할 때 올바른 데이터 위치를 선택하는 것은 성능과 비용 모두에 영향을 미칩니다. 대용량 페이로드를 허용하는 외부 함수는 메모리 할당을 방지하기 위해 매개변수를 호출 데이터로 선언해야 합니다. 이러한 최적화는 특히 토큰 전송이나 일괄 등록과 같은 대량 작업을 처리하는 계약의 경우 가스 사용량을 줄이고 확장성을 향상시킵니다.

2. 내부 및 비공개 함수는 외부에서 호출되지 않으므로 calldata를 사용할 수 없습니다. 대신 데이터 지속 여부에 따라 메모리나 스토리지에 의존합니다. 임시 구조와 관련된 로컬 계산은 높은 스토리지 쓰기 비용을 피하면서 메모리 속도의 이점을 얻습니다.

3. 참조 유형을 잘못 할당하면 의도하지 않은 동작이 발생할 수 있습니다. 지역 변수를 저장소로 선언하고 이를 상태 변수에 할당하면 복사본이 아닌 별칭이 생성됩니다. 지역 변수를 수정하면 원래 상태가 직접 변경됩니다. 이는 어떤 경우에는 바람직할 수 있지만 의도하지 않게 수행하면 위험할 수 있습니다.

4. 정렬이나 필터링과 같은 복잡한 작업은 직접적인 상태 조작이 필요하지 않은 한 메모리 복사본에서 작동해야 합니다. 스토리지 배열의 메모리 스냅샷을 생성하면 실행 중에 일관되지 않은 상태 변경 위험 없이 안전하게 변환할 수 있습니다. 처리 후 필요한 경우 결과를 저장소에 다시 쓸 수 있습니다.

자주 묻는 질문

calldata의 데이터를 수정하려고 하면 어떻게 되나요? calldata에 있는 데이터를 수정하려고 하면 컴파일 오류가 발생합니다. Calldata는 엄격히 읽기 전용이며, 실행 중 변형을 허용하지 않고 외부 함수 호출에 대한 입력 매개변수를 유지하도록 설계되었습니다.

동일한 트랜잭션의 다른 기능에서 메모리 데이터에 액세스할 수 있나요? 아니요, 메모리는 실행 기능과 분리되어 있습니다. 동일한 트랜잭션 내에서도 각 함수 호출은 고유한 새로운 메모리 공간을 얻습니다. 그러나 한 번의 함수 호출 중에 스토리지에 대한 상태 변경은 동일한 트랜잭션의 후속 호출에서 볼 수 있습니다.

값을 메모리에 복사하지 않고 저장소에서 직접 반환할 수 없는 이유는 무엇입니까? 배열이나 문자열과 같은 복잡한 유형을 반환할 때 EVM은 해당 유형을 응답에 포함하기 전에 메모리에 배치해야 합니다. 반환 값에 대해 저장소를 직접 직렬화할 수 없습니다. 따라서 소스가 상태 변수인 경우에도 메모리에 임시 복사본이 필요합니다.

통화 데이터에 저장할 수 있는 데이터 양에 제한이 있나요? EVM 사양에는 고정된 크기 제한이 정의되어 있지 않지만 실질적인 제약은 블록 가스 제한에서 비롯됩니다. 통화 데이터가 지나치게 크면 거래 비용이 너무 높아 블록에 포함할 수 없게 되어 현재 네트워크 상태와 가스 가격에 따라 사용 가능한 크기가 효과적으로 제한될 수 있습니다.