MSG.Sender와 TX.origin의 차이점은 무엇입니까?

이더 리움 스마트 계약 실행의 기본 이해

이더 리움 블록 체인 에서 스마트 계약은 거래 및 기능 통화를 통해 사용자 및 기타 계약과 상호 작용합니다. 견고성을 사용하여 스마트 계약을 개발하거나 분석 할 때 MSG.Sender 와 TX.origin 의 차이점을 이해하는 것이 필수적입니다. 둘 다 계약 실행 중에 주소 정보를 검색하는 데 사용되는 글로벌 변수이지만 , 뚜렷한 목적을 수행하고 다양한 상황에서 다르게 행동합니다.

Msg.sender는 현재 함수의 즉각적인 발신자를 나타냅니다. 이것은 외부 소유 계정 (EOA) 또는 다른 계약 일 수 있습니다. 계약과 현재 상호 작용을 시작한 사람을 결정하는 데 가장 일반적으로 사용되는 변수입니다.

반면에 TX.origin은 발생한 중간 통화 수에 관계없이 거래의 원래 발신자를 나타냅니다. 트랜잭션 체인을 시작한 EOA로 거슬러 올라갑니다.

스마트 계약에서 MSG.Sender의 작동 방식

견고성 계약의 함수가 호출되면 MSG.Sender 변수는 함수를 직접 호출 한 주소로 설정됩니다. 이로 인해 액세스 제어 또는 권한 기반 로직에서 즉각적인 발신자를 식별하기위한 신뢰할 수있는 소스가됩니다.

예를 들어:

 pragma solidity ^0.8.0; 계약 예 {

address public owner; constructor() { owner = msg.sender; } function changeOwner(address newOwner) public { require(msg.sender == owner, 'Only the owner can change ownership'); owner = newOwner; }
 }

이 계약에서 MSG.Sender는 현재 소유자 만 changeOwner 기능을 호출 할 수 있도록합니다. 다른 계약이 다른 사람을 대신 하여이 기능을 호출하면 MSG.Sender는 원래 사용자가 아닌 계약이됩니다.

스마트 계약에서 TX.origin의 작동 방식

TX.origin 변수는 여러 계약 전화가 이루어 지더라도 항상 전체 트랜잭션을 시작한 외부 소유 계정 (EOA) 을 가리 킵니다. 거래 뒤에있는 원래 사용자, 특히 복잡한 계약 상호 작용에서 알아야 할 때 유용합니다.

다음은 그 행동을 설명하는 예입니다.

 pragma solidity ^0.8.0; 계약 a {

function callB(B _b) public { _b.checkOrigin(); }
 }
 
계약 B {
 
function checkOrigin() public { emit LogOrigin(msg.sender, tx.origin); }
 }

이 시나리오에서 EOA가 계약 A에서 callB 호출하는 경우 :

• msg.sender 내부의 checkOrigin() 은 계약 A의 주소가됩니다.
• TX.origin은 거래를 시작한 EOA가 될 것입니다.

이 차이는 중간 계약보다는 원래 사용자를 아는 데 의존하는 논리를 설계 할 때 중요합니다.

TX.origin 사용에 대한 보안 영향

TX.origin을 사용하면 특정 상황에서 보안 위험을 도입 할 수 있습니다. 주요 관심사 중 하나는 피싱 공격 으로 악의적 인 계약이 사용자에게 원래 발신자를 기반으로 민감한 작업을 수행하는 기능을 호출하도록 속이는 것입니다.

예를 들어:

 function transferFromUser(address to, uint amount) public { if (tx.origin == trustedUser) { // Perform transfer }

}

악의적 인 계약은 trustedUser 가이 기능을 호출하는 거래를 시작하도록 속일 수 있으며, 공격자는 TX.origin 에 의존하는 점검을 우회 할 수 있습니다.

따라서 TX.origin을 사용해야 할 특정 이유가없는 한 Access Control을 위해 MSG.Sender를 사용하는 것이 일반적으로 권장됩니다.

MSG.Sender 및 TX.origin의 실제 사용 사례

MSG.Sender 는 소유권 검사, 액세스 제어 및 토큰 전송과 같은 표준 계약 기능에서 널리 사용되지만 TX.Origin에는 더 많은 틈새 응용 프로그램이 있습니다.

MSG.Sender를 사용하십시오.

• 누가 현재 함수를 불렀는지 알아야합니다.
• onlyOwner 와 같은 액세스 수정자를 구현하고 있습니다.
• 무단 계약이 계약과 상호 작용하는 것을 방지하려고합니다.

다음과 같은 경우 tx.origin을 사용하십시오.

• 트랜잭션을 시작하는 원래 사용자를 식별하려고합니다.
• 다른 계약에 의해 트리거되어서는 안되는 논리를 구현하고 있습니다.
• 직접 사용자 상호 작용이 필요한 추천 프로그램 또는 에어 드롭과 같은 시스템을 구축하고 있습니다.

그러나 피싱 공격에 대한 오용과 취약성으로 인해 항상 TX.origin 에주의하십시오.

모범 사례 및 권장 사항

현명한 계약을 개발할 때는 이러한 모범 사례를 따르십시오. 일반적인 함정을 피하십시오.

• 달리 할 수있는 강력한 이유가 없다면 MSG.Sender를 선호 하십시오.
• 계약의 통화 흐름과 MSG.Sender 및 TX.origin이 실행하는 동안 어떻게 변경되는지 이해하십시오.
• 원래 배우가 EOA인지 확인 해야하는 시나리오에서만 TX.origin을 사용하십시오.
• TX.origin 사용에 대한 코드를 감사하고 불필요한 위험을 도입하는지 평가하십시오.

MSG.Sender 와 TX.origin 의 뉘앙스를 이해함으로써 개발자는보다 안전하고 예측 가능한 스마트 계약을 작성할 수 있습니다.

자주 묻는 질문

Q : MSG.Sender가 계약 주소가 될 수 있습니까? 예, MSG.Sender는 기능을 호출 한 사람에 따라 외부 소유 계정 (EOA) 또는 계약 주소가 될 수 있습니다. 계약이 다른 계약에서 기능을 호출하면 MSG.Sender 는 전화 계약의 주소가됩니다.

Q : TX.origin은 항상 EOA입니까? 예, TX.origin은 항상 거래를 시작한 외부 소유 계정 (EOA) 입니다. Call Chain에 여러 계약이 관여하더라도 TX . Origin은 원래 사용자 주소로 남아 있습니다.

Q : TX.origin을 조작 할 수 있습니까? TX.origin은 직접 위조 할 수는 없지만 피싱 공격에서 악용 될 수 있습니다. 예를 들어, 악의적 인 계약은 사용자가 의도하지 않은 조치를 수행하는 거래를 트리거하여 TX.origin 확인에 의존하여 승인을받을 수 있습니다.

Q : 계약에서 TX.origin을 사용하지 않아야합니까? 절대적으로 필요하지 않는 한 TX.origin을 사용하지 않는 것은 일반적으로 더 안전합니다. 보안을 손상시키는 방식으로 사용될 수 있으므로 많은 모범 사례는 액세스 제어 및 상태 변화 기능을 위해 MSG.Sender를 사용하는 것이 좋습니다.