부모와 자녀 간의 메시지 인증

위의 사용자 사례에서 우리는 전체 흐름이 여러 메시지에 분산되어 있음을 확인했습니다. 예를 들어, 메시지는 internal transfer수신자가 SHIB 잔액을 늘리도록 합니다 (기억하시겠지만 이 메시지는 전송 흐름의 끝에서 전송되었습니다). 만약 공격자가 이 메시지를 위조하여 자신의 SHIB 잔액을 보유하고 있는 컨트랙트로 보내려고 하면 어떻게 될까요? 우리가 주의하지 않으면 그러한 위조로 인해 공격자가 허공에서 스스로 새 토큰을 생성할 수 있는 능력이 생길 수 있습니다!

이 위조로부터 컨트랙트을 보호하려면 잔액을 변경하는 이러한 중요한 메시지가 실제로 유효한 발신자로부터 온 것인지 인증해야 합니다. 여기에서 확인 코드를 볼 수 있습니다.

• Jetton_master_address 컨트랙트는 생성자 부모 (어떤 이유로 레이블이 지정됨) 또는 유효한 자식 중 하나가 메시지를 보낸 경우에만 메시지를 처리합니다

이것은 매우 흥미로운 질문으로 이어집니다. 임의의 주소가 유효한 자식 jetton 주소인지 어떻게 알 수 있습니까? 잠깐만요, 아까 앨리슨이 베키에게 메시지를 보내려고 했을 때 처음에 베키의 컨트랙트 주소를 어떻게 알았죠?

이것은 다시 아름다운 시스템 설계입니다. TON의 스마트 컨트랙트에 대한 주소는 컨트랙트의 초기 코드 셀 (구현의 컴파일된 TVM 바이트코드)과 컨트랙트의 초기 데이터 셀 (건설 시점의 초기 지속 상태에서 파생됩니다). 이 두 값을 알면 컨트랙트가 배포되기 전에도 컨트랙트의 주소를 계산할 수 있습니다. 이 계산은 결정론적이며 변경할 수 없습니다.

Jetton 코드에는 Alison의 주소를 기반으로 자녀의 주소 (Alison의 SHIB 잔액을 보유한 컨트랙트의 주소)를 계산하는 유틸리티 함수가 포함되어 있습니다. 여기에서 이 기능을 볼 수 있습니다. 보시다시피 실제로 자식의 초기 코드 셀 과 초기 데이터 셀 에 따라 달라집니다.

이 메커니즘이 안전한 이유를 이해하는 것은 약간 까다롭습니다. 공격자가 법적 자녀 중 하나의 주소에 악의적인 컨트랙트를 배포하지 못하도록 막는 것은 무엇입니까? 법적 주소에 도달하려면 악의적인 컨트랙트에 공식 자식의 초기 코드 셀이 있어야 합니다. 이는 이미 공격자가 이 구현에 악성 코드를 추가할 수 있는 능력을 제한했습니다. 또한 초기 데이터 셀은 초기 데이터 셀에 주소가 포함되어 있기 때문에 자식이 올바른 생성자 부모에게만 복종하도록 보장합니다.