모든 게시물

계약서 읽기 vs 계약서 작성

blockchainFebruary 6, 2026·#Blockchain

스마트 계약의 운영 메커니즘에 대한 포괄적인 견해, 체인에서 데이터 읽기와 쓰기 사이의 유해한 혼란을 해독하고 전문가 Tan Phat Digital의 안전 지침을 제공합니다.

계약서 읽기 vs 계약서 작성

분산금융(DeFi)과 블록체인 기반 애플리케이션 시대에 Etherscan과 같은 블록 탐색기를 통해 스마트 계약과 직접 상호 작용하는 것은 필수 기술이 되었습니다. 그러나 Tan Phat Digital 전문가 팀의 관찰에 따르면 두 가지 주요 상호 작용 방법인 "계약 읽기"와 "계약 쓰기"의 근본적인 차이점을 오해하는 경우가 많아 비용, 실행 속도, 특히 디지털 자산의 안전성에 대한 혼란을 초래합니다. 다음 분석에서는 사용자가 자주 접하는 EVM(Ethereum Virtual Machine)의 기술 아키텍처, 토큰 표준 및 취약점을 자세히 조사합니다.

아키텍처 원리: 가변 상태와 데이터 쿼리의 분리

읽기 작업과 쓰기 작업을 구별하는 기초는 Ethereum 네트워크가 데이터를 저장하는 방식에 있습니다. Solidity의 상태 변수는 블록체인에 영구적으로 저장되며 모든 노드에서 유지 관리하는 네트워크 상태의 일부입니다. 이러한 변수에 액세스하거나 수정하려면 EVM에서 다양한 실행 메커니즘이 필요합니다.

읽기 작업

Etherscan의 "계약 읽기" 탭으로 표시되는 읽기 작업은 블록체인 상태를 변경하지 않고 계약에 암호화되거나 저장된 정보를 쿼리하는 프로세스입니다. 기술적으로 이러한 함수는 view 또는 pure와 같은 수정자를 사용하여 정의되는 경우가 많습니다. 보기 함수를 사용하면 상태 변수나 잔액을 읽을 수 있지만 이를 수정하지는 않는 반면, 순수 함수는 상태를 읽거나 쓰지 않고 입력 매개변수에 따라 계산만 수행한다는 점에서 훨씬 더 제한적입니다.

종종 사용자를 혼동시키는 핵심 사항은 이러한 작업의 '무료' 특성입니다. 사용자가 Etherscan을 통해 잔액이나 토큰 이름을 쿼리하면 브라우저는 RPC 프로토콜(eth_call)을 통해 Ethereum 노드를 호출(call)합니다. 이 작업은 네트워크의 전체 상태를 변경하지 않으므로 글로벌 합의가 필요하지 않으므로 가스 비용이 들지 않습니다. 그러나 이러한 읽기 기능이 온체인의 다른 쓰기 기능에 의해 호출될 때 미묘한 오해가 발생합니다. 그러한 맥락에서 그들은 여전히 ​​전체 거래의 일부로 가스를 소비합니다.

쓰기 작업

반면, "계약 쓰기" 탭은 자금 이체, 소유권 업데이트 또는 토큰 사용 권한 승인과 같이 블록체인 상태를 변경하는 작업을 나타냅니다. 모든 상태 변경은 원장에 영구적으로 기록되어야 하며, 이를 위해서는 사용자가 실제로 트랜잭션(트랜잭션)을 제출해야 합니다. 이 거래에는 전송 주소에 대한 통제권을 증명하기 위해 사용자 지갑(예: MetaMask)의 디지털 서명이 필요합니다.

비용과 시간 차이는 분명합니다. 쓰기 작업은 계산 비용의 척도인 가스를 소비하며 채굴자나 검증자가 이를 블록에 압축할 때까지 기다려야 합니다. 사용자는 가스 가격 변동을 예측하지 못하는 실수를 저지르며, 부적절한 가스 한도 설정으로 인해 거래가 중단되거나 실패하는 경우가 많습니다.

읽기 및 쓰기 계약의 비교 특성 분석

1. 계약(호출) 작업 읽기:

  • 주요 목적: 블록체인에서 현재 데이터를 쿼리합니다.

  • 견고성 수정자: 키워드 view 또는 pure를 사용합니다.

  • 가스 요금(오프체인): 쿼리할 때 완전히 무료입니다. 브라우저 탐색.

  • 지갑 서명 필요: 개인 지갑에서는 서명이 필요하지 않습니다.

  • 네트워크 영향: 로컬 노드 수준에서만 발생합니다.

  • 응답 시간: 응답은 거의 즉각적입니다.

  • 실패 가능성: 매우 낮음, 일반적으로 소스 코드의 논리 오류로 인해 발생함.

2. 계약(트랜잭션) 작업 쓰기:

  • 주요 목적: 블록체인의 상태 또는 데이터를 변경합니다.

  • 견고성 수정자: 제한 없음 키워드(또는 payable 사용).

  • 가스 요금: 항상 네트워크 기반에서 가스 요금을 지불해야 합니다. 통화.

  • 지갑 서명 필요: 소유권을 인증하려면 서명이 필요합니다.

  • 네트워크 영향: 합의 메커니즘을 통한 글로벌 영향.

  • 응답 시간: 속도 네트워크 성능 및 가스 가격에 따라 다름.

  • 실패 가능성: 높음, 가스 부족, 잘못된 임시값, 권한 오류 또는 계약 논리로 인해 발생 가능.

자세히 보기: Blockchain Explorer란 무엇입니까?

계약 쓰기 작업의 일반적인 실수 분석

Etherscan의 "계약 쓰기" 인터페이스와 직접 상호 작용할 때 사용자는 보호 계층을 우회하는 경우가 많습니다. 일반 dApp 인터페이스의 경우 엄격한 기술 요구 사항을 직접적으로 직면해야 합니다.

소수점 정밀도 실수

이는 Tan Phat Digital이 경고하고 싶은 직접적인 금전적 손실을 초래하는 가장 일반적인 기술적 위험입니다. Solidity에서는 네트워크가 부동 소수점 숫자를 지원하지 않기 때문에 정수(uint256)가 선호됩니다. 따라서 모든 토큰에는 decimals 매개변수가 있습니다.

사용자들은 종종 모든 토큰이 ETH와 유사한 표준 18자리 십진수를 사용한다고 잘못 생각합니다. 그러나 실제로는 큰 차이가 있습니다.

  • 이더리움(ETH): 소수점 이하 18자리. 1단위의 원래 값은 1 x 10^{18}(Wei)입니다.

  • 래핑 비트코인(WBTC): 소수점 8자리. 1단위의 원래 값은 1 x 10^8(사토시)입니다.

  • 테더(USDT): 소수점 이하 6자리. 1개 단위의 원래 값은 1 x 10^6입니다.

  • USD 코인(USDC): 소수점 이하 6자리. 1단위의 원래 값은 1 x 10^6입니다.

  • DAI Stablecoin: 소수점 18자리. 1개 단위의 원래 값은 1 x 10^{18}입니다.

  • 시바견(SHIB): 소수점 18자리. 1단위의 원래 값은 1 x 10^{18}입니다.

예: 1,000 USDC를 이체하려면 1000000000을 입력해야 합니다. 1000만 입력하면 실제 전송되는 금액은 0.001 USDC에 불과합니다.

계산 오류: 곱하기 전 나누기 및 반올림

스마트 계약에서 곱하기 전에 나누기를 수행하는 것은 전형적인 실수입니다. uint256은 항상 반내림되므로 중간 계산에서 1보다 작은 결과가 반환되면 즉시 0이 됩니다. 사용자는 '쓰기' 기능에 매개변수를 제공할 때 이러한 논리적 오류 조건이 발생하지 않도록 순서에 주의해야 합니다.

자세히 보기: 트랜잭션 ID(TxID)는 다음과 같습니다. 무엇입니까?

승인 생태계 및 보안 함정

"승인" 메커니즘을 사용하면 제3자가 사용자를 대신하여 토큰을 사용할 수 있지만 이는 종종 악용되는 약점이기도 합니다.

무한 승인 신화

대부분의 dApp에서는 나중에 가스를 절약하기 위해 "무한" 승인이 필요합니다. 사용자는 해당 계약에 잔액을 완전히 제어할 수 있다는 사실을 이해하지 못한 채 uint256의 최대값을 복사하는 경우가 많습니다. 계약이 해킹되면 공격자는 추가 확인 없이 지갑을 비울 수 있습니다.

연결 해제와 취소 사이의 혼동

많은 Web3 사용자는 "연결 해제" 지갑이 안전하다고 생각하지만 그렇지 않습니다.

1. 지갑 연결 해제:

  • 배치: dApp 인터페이스 또는 지갑 위젯에서 작업.

  • 가스 요금: 완전 무료.

  • 영향: 웹사이트 인터페이스에서는 지갑 주소만 숨깁니다. 스마트 계약은 이전에 승인된 철회 권리를 유지합니다.

  • 목적: 개인정보를 보호합니다.

2. 승인 취소:

  • 목적: 절대 자산 보안.

프록시 아키텍처 및 트랜잭션 오류

프로젝트에서는 종종 "프록시 계약" 모델을 사용하여 소스 코드를 업그레이드합니다. 프록시 주소와 구현 주소를 혼동하면 오류가 발생하는 경우가 많습니다. 사용자는 "이것이 프록시입니까?" Etherscan에서 "프록시로 읽기" 또는 "프록시로 쓰기" 탭과 올바르게 상호 작용합니다.

쓰기 계약 실행 시 디코딩 오류

  • 가스 부족 오류: 설정한 가스 한도가 필요한 것보다 낮을 때 발생합니다. 지불한 가스 요금은 모두 손실되며 거래가 실패하게 됩니다. 복잡한 계약 상호작용의 경우 가스를 21,000으로 기본값으로 설정하지 마세요.

  • 실행 되돌림 오류: 가스는 충분하지만 잘못된 인증, 잔고 부족 또는 요구 조건 위반으로 인해 계약 로직이 중지되었습니다. 가스를 늘려도 이 오류가 해결되지 않습니다.

  • Nonce 오류: 각 거래에는 시퀀스 번호(nonce)가 있습니다. 수수료가 낮은 거래가 중단되면 nonce가 더 큰 후속 거래도 중단되어 지갑 정체가 발생합니다.

인덱싱 데이터 및 탐색기 지연 시간

Etherscan에는 몇 초에서 몇 분 범위의 인덱싱 지연이 있습니다. 지갑이 성공을 보고했지만 Etherscan이 아직 새로운 데이터를 표시하지 않아 낭비적인 거래가 반복적으로 전송될 때 사용자는 당황하는 경우가 많습니다.

게다가 데이터 분류도 혼란스럽습니다.

  • 거래 탭: 고유한 해시 코드(Tx 해시)와 함께 개인 지갑에서 직접 호출을 표시합니다.

  • 내부 거래 탭: 계약 논리에 따라 수행되는 ETH 이동입니다. 별도의 Tx 해시는 없지만 원래 거래에 따라 다릅니다.

  • 토큰 전송 탭: 계약에서 발생한 이벤트를 기반으로 ERC-20, 721, 1155 표준의 전송을 표시합니다.

15가지 자주 묻는 질문(FAQ)

  1. 지갑 잔액을 읽을 수 있는 이유는 무엇입니까? 수수료 없이 Etherscan 이상으로?

    읽기 작업은 블록체인 상태를 변경하지 않습니다. Etherscan은 로컬 노드의 데이터만 쿼리하고 이를 표시하므로 가스나 지갑 서명이 필요하지 않습니다.

  2. 계약 읽기 탭의 "보기" 기능과 "순수" 기능의 차이점은 무엇입니까?

    둘 다 오프체인에서 호출할 때 가스가 없습니다. 하지만 view 함수는 계약의 상태 변수에서 데이터를 읽을 수 있지만 pure는 읽거나 쓰지 않고 입력에 따라 계산만 수행합니다.

  3. Write Contract(계약 쓰기) 탭에서 100 USDT를 이체하면 지갑에 0.0001 USDT만 표시되는 이유는 무엇입니까? 소수점 오류로 인해. USDT에는 소수점 이하 6자리만 있습니다. "100"을 입력하면 시스템은 이를 $100 / 10^6$로 해석합니다. 100 USDT를 전송하려면 100000000을 입력해야 합니다.

  4. "가스 부족"은 "실행 되돌림"과 어떻게 다릅니까?

    "가스 부족"은 가스 한도를 너무 낮게 설정했기 때문에 채굴자가 코드를 완전히 실행할 만큼 에너지가 충분하지 않기 때문입니다. "되돌림"은 가스는 충분하지만 특정 조건(예: 잘못된 비밀번호 또는 지갑 부족)이 충족되지 않아 계약 로직이 거래를 적극적으로 중지하기 때문입니다.

  5. dApp에서 지갑 연결을 끊었습니다. 해커가 내 자금을 다시 인출할 수 있나요?

    예. 연결 끊기는 디스플레이 인터페이스를 중단할 뿐입니다. 귀하가 서명한 "승인" 권한은 "취소" 작업을 수행할 때까지 블록체인에서 영원히 유효합니다.

  6. Etherscan에 "이 계약은 프록시 계약일 수 있습니다"라고 표시되는 이유는 무엇입니까?

    이 계약은 업그레이드가 가능하도록 프록시 모델을 사용하기 때문입니다. 모든 구현 논리는 다른 계약(구현)에 있습니다. "프록시로 읽기/쓰기" 탭을 사용하려면 프록시를 확인해야 합니다.

  7. 무한 승인은 얼마나 위험한가요?

    이를 통해 해당 계약은 언제든지 전체 토큰 잔액을 인출할 수 있습니다. 프로젝트가 해킹되었거나 프로젝트 소유자가 나쁜 의도를 갖고 있는 경우, 귀하가 이를 막을 수 없는 상태에서 지갑을 비울 수 있습니다.

  8. Etherscan에서 이전 승인 권한을 취소하는 방법은 무엇입니까?

    Etherscan의 "토큰 승인 검사기" 섹션으로 이동하여 지갑을 연결하고 더 이상 신뢰하지 않는 각 계약에 대해 "취소" 버튼을 누르십시오. 이 작업에는 약간의 가스 요금이 부과됩니다.

  9. MetaMask에서 내 거래가 성공적으로 보고되었지만 Etherscan에는 여전히 이전 잔액이 표시됩니까?

    이것은 인덱싱 지연 현상입니다. 체인의 데이터는 업데이트되었지만 Etherscan의 서버 시스템은 새로운 데이터를 동기화하고 표시하는 데 몇 초에서 몇 분이 필요합니다.

  10. "내부 트랜잭션"이란 무엇이며 왜 자체 해시(Tx Hash)가 없나요?

    이는 계약 내부 논리에서 발생하는 거래입니다(예: 계약이 자동으로 ETH를 보냅니다). 원래 거래(일반 거래)에 포함되어 있어 독립적인 해시 코드가 없습니다.

  11. '이체' 기능을 사용하여 계약 주소로 토큰을 전송하면 돈을 잃나요? 아마도 그럴 것입니다. 일부 계약에는 직접 입금된 토큰을 처리하는 기능이 없으며 영원히 정체될 것입니다. 일반적으로 "입금" 기능이나 공식 dApp 인터페이스를 사용해야 합니다.

  12. 거래하려면 왜 ETH를 WETH로 "래핑"해야 하나요?

    ETH는 ERC-20 표준을 따르지 않고 기본 통화이기 때문입니다. DEX의 "Approve" 또는 "TransferFrom"과 같은 기능과 상호 작용하려면 ETH를 WETH로 래핑하여 표준 토큰이 되어야 합니다.

  13. 주소 중독이란 무엇입니까?

    사기꾼은 귀하가 일반적으로 사용하는 주소와 첫 번째 및 마지막 문자가 동일한 주소에서 극소량의 돈(먼지)을 보냅니다. 그 목적은 다음 전송 시 거래 내역에서 주소를 실수로 복사하는 것입니다.

  14. ERC-2612 "허가"는 기존 "승인"보다 안전합니까? "허가"는 오프체인 서명으로 인해 가스를 절약하는 데 도움이 되지만 서명 피싱의 위험이 있습니다. 해커는 무해해 보이지만 실제로는 돈 인출 권한을 부여하는 메시지에 서명하도록 속일 수 있습니다.

  15. Wei는 1ETH는 몇 개인가요?

    스마트 계약 프로그래밍에서 가장 작은 단위는 Wei입니다. 1 ETH = 10^{18} 웨이(1,000,000,000,000,000,000 웨이). Write Contract 탭에 값을 수동으로 입력할 때 항상 이 숫자를 염두에 두십시오.

Read와 Write Contract의 차이점을 이해하는 것은 Web3 세계에서 당신을 보호하는 가장 강력한 방패입니다. Tan Phat Digital은 사용자에게 다음을 권장합니다.

  1. 항상 각 토큰 유형의 소수점 이하 자릿수를 확인하세요.

  2. 제한된 승인의 우선순위를 지정하고 주기적으로 "취소"를 수행하세요.

  3. 프록시 테스트 도구를 사용하여 명령이 올바른 주소로 전송되는지 확인하세요.

  4. 가스를 늘리는 대신 오류를 차분하게 디코딩하세요. 맹목적으로.

  5. 공개적으로 확인된(검증된) 계약서와만 상호 작용합니다.

Web3는 재정적 자율성을 제공하지만 이에 상응하는 개인적인 책임도 요구합니다. Tan Phat Digital의 공유가 블록체인에서 더욱 안전하고 효과적으로 상호 작용하는 데 도움이 되기를 바랍니다.

공유

댓글

0.0 / 5(0 개의 평가)

댓글을 남기려면 로그인하세요.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요.