Ether를 다른 계약으로 안전하게 보내는 방법은 무엇입니까?

스마트 계약으로 Ether 보내기: 주요 고려 사항

1. 수신 계약에 지불 가능한 대체 기능 또는 Ether를 수용할 수 있는 지정된 지불 기능이 있는지 확인하십시오. 이것이 없으면 모든 이체가 취소되어 잠재적으로 자금이 영구적으로 잠길 수 있습니다.

2. 외부 계약과 상호작용할 때 address(contract).call{value: amount}('')를 주의해서 사용하세요. 남은 가스를 모두 전달하고 기본 안전 확인 기능이 없기 때문입니다. 이 방법은 컴파일 타임 검사를 우회하고 적절하게 보호되지 않으면 트랜잭션이 재진입 공격에 노출될 수 있습니다.

3. 이전 Solidity 버전의 하위 수준 호출보다 .transfer() 또는 .send() 사용을 선호합니다. 가스 전달을 2300 단위로 제한하여 수신 중 악성 코드 실행 위험을 줄입니다. .send() 는 실패 시 되돌리는 대신 false를 반환하므로 명시적인 오류 처리가 필요합니다.

4. Ether를 보낼 때 항상 자신의 계약에 검사-효과-상호작용 패턴을 구현하십시오. 재귀 콜백 중에 자금이 고갈될 수 있는 재진입 악용을 방지하기 위해 외부 계약을 호출하기 전에 상태 변경이 발생하는지 확인하세요.

5. 대상 계약의 소스 코드가 검증되고 감사되는지 확인합니다. 게시된 코드 없이 배포된 계약은 상호 작용 전에 해당 동작을 독립적으로 검증할 수 없기 때문에 상당한 위험을 초래합니다.

이더 전송 시 흔히 발생하는 함정 방지

1. 계약이 존재한다고 해서 Ether를 받을 수 있다고 가정하지 마십시오. 많은 계약은 특정 조건이 충족되지 않는 한 폴백 기능을 되돌려 직접 Ether 수신을 명시적으로 차단합니다.

2. Ether를 전달할 때 위임자 호출 사용에 주의하십시오. Delegatecall은 호출 계약의 컨텍스트에서 코드를 실행하므로 이를 가치 전송과 결합하면 예기치 않은 저장소 수정 및 자금 손실이 발생할 수 있습니다.

3. web3 인터페이스를 통해 Ether를 보낼 때 가스 추정 오류가 있는지 확인하세요. 일부 지갑은 수신자 계약에 필요한 추가 계산을 설명하지 못하여 겉보기에 충분한 한도가 있어도 가스 부족 오류가 발생할 수 있습니다.

4. 프로덕션 환경에서는 주소를 하드코딩하지 마세요. 대신 등록된 계약 참조나 배포 중에 초기화된 불변 변수를 사용하여 잘못된 전송 가능성을 줄이세요.

5. 고부가가치 전송을 실행하기 전에 메인넷과 동일한 구성을 사용하여 테스트넷에서 트랜잭션을 테스트합니다. 컴파일러 버전이나 네트워크 조건의 차이로 인해 계약 동작이 예기치 않게 변경될 수 있습니다.

계약 간 Ether 흐름에 대한 보안 관행

1. 가능하다면 푸시결제 대신 출금 패턴을 구현하세요. 사용자가 Ether를 직접 푸시하는 대신 자금을 인출할 수 있도록 하여 전송 실패 및 서비스 거부 벡터에 대한 노출을 최소화합니다.

2. 단일 계약 내에서 반복되는 Ether 전송에 속도 제한을 적용하여 공격자가 반복적인 상호 작용을 강제하여 잔액을 조작하거나 의도하지 않은 부작용을 유발하는 잠재적 남용 시나리오를 완화합니다.

3. 안전한 전송을 위해 OpenZeppelin의 Address.sol 라이브러리를 활용하세요. 해당 함수 sendValue 에는 자동 성공 확인 및 실패 시 되돌리기가 포함되어 보안 Ether 디스패치를 ​​단순화합니다.

4. .send() 사용 시 자동 실패를 모니터링합니다. 실패 시 되돌리는 .transfer() 와 달리 .send() 는 부울 값을 반환합니다. 결과 확인을 게을리하면 눈에 띄지 않는 자금 보유 문제가 발생할 수 있습니다.

5. 공개 접근성이 엄격하게 필요한 경우가 아니면 onlyOwner 또는 역할 기반 제어와 같은 수정자를 사용하여 Ether 전송 기능에 대한 액세스를 제한합니다. 무제한 기능은 무단 자금 분산에 대한 공격 표면을 증가시킵니다.

자주 묻는 질문

계약서에서 Ether를 받았지만 처리할 수 없으면 어떻게 되나요? 계약에 지불 가능한 폴백 또는 수신 기능이 없는 경우 Ether를 보내려고 하면 거래가 취소됩니다. 이는 발신자를 우발적인 손실로부터 보호하지만 전송을 시작하기 전에 신중한 확인이 필요합니다.

Ether를 다른 곳으로 보낸 후 계약이 자체 파괴되어 Ether를 회수할 수 있습니까? 예, selfdestruct(address) opcode를 통해 해당 주소가 일반적으로 Ether를 거부하더라도 계약은 잔액을 다른 주소로 강제로 보낼 수 있습니다. 이는 일반적인 수신 논리를 우회하며 침입적 특성으로 인해 자제해서 사용해야 합니다.

생성자 함수에서 msg.value를 사용하는 것이 안전합니까? 생성자는 지불 가능으로 표시된 경우 배포 중에 Ether를 수락할 수 있습니다. 그러나 초기화 시 논리적 오류가 발생하면 업그레이드 경로 없이 자금이 잠기거나 잘못 할당될 수 있으므로 극도의 주의가 필요합니다.

EIP-1884는 계약으로의 Ether 전송에 어떤 영향을 미치나요? EIP-1884는 Ether를 받는 계약의 가스 계산에 영향을 미치는 SLOAD와 같은 특정 opcode의 비용을 증가시켰습니다. 이전에 성공한 트랜잭션, 특히 수신 중에 복잡한 대체 논리에 의존하는 트랜잭션의 경우 이제 가스가 부족할 수 있습니다.