메르세데스' blog

글

메타마스크 주소 오염 경고, 송금 전 전체 주소와 네트워크를 확인하는 법

- 9월 15, 2026

메타마스크에서 주소 오염 경고가 뜨면 보내기를 멈추고, 받는 사람의 원본 수신 화면에서 주소를 다시 확인하세요. 거래 내역에 남은 주소의 앞뒤가 익숙해도 가운데가 다를 수 있어요. 전체 주소와 네트워크를 대조한 뒤, 시험 전송을 했다면 실제 수신처에 입금이 반영됐는지까지 확인해야 합니다. 주소의 앞뒤가 닮아도 수신처가 같지는 않습니다. 원본 화면과 전체 주소를 대조해야 합니다. 핵심 요약 주소 오염은 거래 내역에 닮은 주소를 끼워 넣어 다음 송금을 잘못 보내게 만드는 수법이에요. 지갑의 경고는 재확인을 돕지만 주소의 안전성을 보증하지 않습니다. 원본 수신 주소 확보, 붙여넣은 전체 주소 대조, 양쪽 네트워크 일치, 실제 도착 확인을 한 흐름으로 묶어 두세요. 메타마스크 경고에서 달라진 것은 확인하는 시점이에요 MetaMask는 2026년 6월 17일 주소 오염 탐지 기능 도입 을 발표했어요. 과거 상호작용한 주소와 새로 붙여넣은 주소를 비교하고, 앞뒤가 닮았는데 가운데가 다르면 송금 전에 경고를 띄우는 방식입니다. 처음 보내는 주소에도 별도의 주의 알림을 제공한다고 밝혔어요. 회사 발표에 적힌 적용 대상은 모바일과 브라우저 확장 프로그램의 EVM 네트워크예요. EVM은 이더리움과 호환되는 실행 환경을 가리킵니다. 2026년 9월 15일 확인한 공식 도움말에도 같은 보호 방식이 안내돼 있지만, 이 글에서 모든 기기의 설치 버전과 경고 화면을 직접 시험한 것은 아니에요. 특정 최소 버전이나 다른 계열 네트워크의 지원까지 넓혀 말하지 않겠습니다. 이제 송금 직전에 지갑이 한 번 더 멈춰 세워 줍니다. 다만 기능을 만든 회사의 설명이므로 모든 사기를 탐지한다는 독립적인 성능 검증으로 읽어서는 안 됩니다. 경고가 없다는 사실만으로 수신자가 내가 의도한 상대라고 결론 내릴 수는 없어요. 낯선 소액 거래가 내역에 들어오는 이유 누구나 볼 수 있는 블록체인 거래 기록은 공격자에게도 보입니다. 공격자는 이용자가 자주 쓰는 주소와 일부 문자가 비슷한 주소를 만들...

메타마스크 토큰 승인 취소, 연결 해제 뒤 남은 권한을 확인하고 지우는 법

- 9월 12, 2026

메타마스크에서 사이트 연결을 끊어도, 이미 블록체인에 남긴 토큰 사용 승인은 사라지지 않아요. 디파이를 더 쓰지 않거나 수상한 사이트에 승인했다면 사용한 네트워크에서 토큰·승인받은 주소·잔여 한도를 확인하고 불필요한 승인을 취소 해야 합니다. 취소 거래가 성공했는지 확인하는 것까지가 정리의 끝이며, 이미 유출된 자산이나 복구 문구 문제는 별도로 대응해야 해요. 사이트 연결 종료와 블록체인에 기록된 토큰 사용 승인 취소는 서로 다른 작업입니다. 핵심 요약 연결 해제는 사이트와 지갑의 접속 관계를 정리하고, 승인 취소는 특정 주소가 내 토큰을 사용하는 권한을 줄여요. 조회는 공개 주소로 시작할 수 있지만 취소에는 서명과 네트워크 수수료가 필요합니다. ‘승인 없음’이라는 화면도 선택한 계정·체인·토큰 범위 안에서만 판단해야 해요. 연결은 끊었는데 사용 권한은 왜 남아 있을까요 사이트에서 로그아웃한 것과 그 사이트에 주었던 출금 위임을 철회한 것은 달라요. 메타마스크 연결은 웹사이트가 지갑과 대화하는 통로예요. MetaMask의 연결 해제 안내 도 연결을 끊는 조작이 기존 토큰 승인을 취소하지 않는다고 구분해요. 공개 주소를 이미 아는 상대는 블록체인 기록을 계속 조회할 수 있으므로, 연결 해제가 과거 기록을 감추는 기능도 아닙니다. 반면 ERC-20 승인은 토큰 계약에 남는 권한입니다. 내 주소가 어떤 주소에 얼마까지 토큰을 사용하도록 허용했는지가 핵심이에요. ERC-20 표준 의 approve는 사용 한도를 정하고, allowance는 아직 남은 한도를 보여 줍니다. 권한을 받은 쪽은 그 범위 안에서 transferFrom을 통해 토큰을 옮길 수 있어요. 웹사이트 탭을 닫는 동작은 이 장부를 바꾸지 않습니다. 그래서 지갑 비밀번호를 잘 지키고 복구 문구를 알려 주지 않았더라도 잘못 준 승인이 문제가 될 수 있어요. 이때 확인할 질문은 ‘누가 내 비밀번호를 알까’만이 아니라 ‘어느 주소가 어느 토큰을 사용할 수 있을까’입니다. 한 토큰의 승인이 모든 코인...

이더리움 양자보안 전환, 개인지갑을 옮기기 전에 확인할 공식 안내와 조건

- 9월 10, 2026

이더리움 양자보안 전환 소식을 보고 개인지갑의 ETH를 곧바로 옮길 필요는 없어요. 2026년 9월 7일 이더리움 재단 Protocol 팀이 제시한 2029년 12월 목표는 네트워크 개발 목표이며, 이용자에게 내려진 자산 이전 마감일이 아닙니다. 지금은 사용 중인 지갑의 공식 공지와 지원 조건을 확인하고, ‘양자보안 전환’을 명분으로 복구 문구나 송금을 요구하는 안내를 구분할 때예요. 네트워크 개발 목표와 개인지갑의 실제 전환 안내는 따로 확인해야 합니다. 핵심 요약 양자보안 로드맵 발표만으로 지금의 ETH가 새 토큰으로 바뀌거나 이전 의무가 생기지는 않아요. 프로토콜 준비, 지갑 지원, 내 계정의 적용 여부를 구분하세요. 미래 전환 시점·비용·복구 조건은 실제 제품 공지에서 확인해야 하며, 이번 발표로 정해졌다고 볼 수 없습니다. 2029년 목표에서 달라진 것은 개발 우선순위예요 이더리움 재단의 9월 7일 Protocol 우선순위 발표 는 실행·합의·데이터의 세 계층을 2029년 12월까지 양자 공격에 견디도록 만드는 목표를 제시했어요. 재단은 이더리움 생태계를 지원하는 이해관계자이며, 이 발표는 팀의 개발 방향입니다. 모든 지갑과 서비스의 전환 완료를 보증하는 약속으로 읽어서는 안 돼요. 같은 문서는 암호체계를 위협할 양자컴퓨터가 2030년부터 등장할 수 있다는 공격적인 가정을 계획에 반영했다고 설명합니다. 실제 등장 시기를 예측해 확정한 것은 아니에요. 2027년 1월에는 외부 전문가의 도움으로 진전을 재평가하겠다는 조건도 붙였어요. 목표 날짜와 위험 발생 날짜를 섞으면 ‘그날 이후 잔액이 사라진다’는 잘못된 결론으로 이어집니다. 독자에게 필요한 변화는 뉴스를 읽는 기준이에요. 앞으로는 ‘양자보안 연구를 한다’는 표현보다 어느 기능이 구현·검증됐고 내가 쓰는 지갑이 무엇을 지원하는지 확인해야 합니다. 발표에 적힌 큰 연도 하나만으로 자산 이동을 결정하기에는 중간 단계가 많이 남아 있어요. 왜 지갑 하나를 업데이트하는 것으로 끝나지 않을까요 ...

SEC 이전대리인 규정안, 토큰화 주식에서 공식 주주명부 확인하는 법

- 9월 08, 2026

미국에서 토큰화 주식을 샀다면 블록체인 거래 기록만으로 주주 권리가 확정된다고 단정할 수 없습니다. 2026년 9월 1일 미국 증권거래위원회(SEC)가 공개한 이전대리인 규정 현대화안의 핵심은 전자·블록체인 장부를 인정하는 데 그치지 않고, 누가 공식 소유자 기록을 관리하며 오류·분실·제한표시를 어떻게 처리할지 다시 정하는 데 있어요. 한국 투자자는 ‘온체인’이라는 말보다 공식 주주명부, 이전대리인, 수탁 구조를 먼저 확인해야 합니다. 핵심 요약 SEC 안은 아직 확정 규정이 아닙니다. 다만 토큰화 증권에서도 블록체인 주소와 공식 소유자 기록이 자동으로 같은 뜻이 되지는 않는다는 점을 분명히 보여줍니다. 상품 설명서에서 이전대리인 이름, 공식 기록의 기준 장부, 지갑 분실 시 절차, 거래 제한과 수탁 방식을 함께 확인하세요. 토큰화 증권은 온체인 이동과 공식 소유자 기록이 같은 기준으로 맞물리는지 확인해야 합니다. SEC 이전대리인 규정안은 무엇을 바꾸려 하나 이전대리인(transfer agent)은 발행회사의 공식 증권 소유 기록을 관리하고, 발행·취소·명의 이전을 처리하는 시장 인프라입니다. 종이 주권이 일반적이던 시절에는 주권의 진위와 명의 변경을 확인하는 일이 중심이었어요. 지금은 무권화 증권, 전자 장부, 빠른 결제, 분산원장 기술이 섞이면서 실제 업무가 크게 달라졌지만 미국의 핵심 규정은 1970년대 말과 1980년대 초 이후 실질적인 개편이 드물었습니다. SEC의 2026년 9월 1일 보도자료 는 이번 제안이 전자 통신과 블록체인 기반 기록관리, 무권화 증권의 현실을 반영한다고 설명합니다. 등록·연례 보고 양식을 고치고, 처리 기한·위험관리·활동이 없는 주주 처리 요건을 손보며, 준법 체계와 제한표시 처리에 관한 새 규칙 두 개를 도입하는 구상입니다. 기존 규칙 하나는 폐지 대상으로 제시됐습니다. 여기서 가장 먼저 구분할 것은 ‘제안’과 ‘확정’입니다. 파일 번호는 S7-2026-30, 릴리스 번호는 34-106246이며 SEC ...

CCTP V1 종료 전 V2 전환, USDC 전송 서비스가 확인할 항목

- 9월 05, 2026

CCTP V1을 쓰는 USDC 전송 서비스는 2026년 10월 31일 전에 V2 계약과 API로 전환해야 합니다. 10월 31일부터 V1의 신규 소각 한도가 줄고, 12월 1일에는 V1 계약이 중지될 예정입니다. 지갑 화면에 ‘USDC 전송’이 계속 보여도 내부 경로가 V1이면 어느 순간 새 전송이 멈출 수 있으므로, 사용자는 전송 전 지원 네트워크와 서비스 공지를 확인하고 개발자는 계약 주소·함수·API·수수료 처리를 함께 점검해야 해요. 핵심 요약 CCTP V1 종료는 USDC 잔액이 사라진다는 뜻이 아닙니다. 다만 V1을 통해 새로 시작하는 체인 간 전송은 단계적으로 제한됩니다. 서비스 운영자는 V2의 새 계약과 /v2/ API를 적용하고, 일반 이용자는 소액 전송·도착 체인·네이티브 USDC 여부를 확인한 뒤 큰 금액을 보내는 편이 안전합니다. CCTP V1에서 V2로 옮길 때는 화면 이름보다 실제 계약 주소와 API 경로를 함께 바꿔야 합니다. CCTP V1 종료 일정에서 먼저 기억할 두 날짜 Circle이 2026년 8월 27일 공개한 일정은 두 단계입니다. 10월 31일부터 CCTP V1의 burn limit, 즉 원본 체인에서 새 USDC 전송을 시작할 수 있는 한도가 줄어듭니다. 한 달 동안 성능과 처리 가능량을 낮춰 사용량을 0으로 유도한 뒤 12월 1일 V1 계약을 중지합니다. 이때까지 V1을 호출하는 앱은 체인 간 USDC 전송을 더 시작하지 못할 수 있어요. 이는 가격 전망이나 시장 이벤트가 아니라 서비스 작동 조건의 변경입니다. 전송 버튼이 있는지, USDC 잔액이 보이는지만 확인해서는 부족합니다. 앱이 호출하는 TokenMessenger 계약이 V1인지 V2인지, attestation을 받는 서버가 /v1/ 경로인지 /v2/ 경로인지까지 확인해야 합니다. Circle은 V2 전환을 권고가 아닌 필수로 표현했습니다. 다만 이 발표는 서비스 제공사인 Circle의 운영 공지이므로 실제 사용 중인 지갑·거래소·브리지의...

Core Lightning 26.06.7 보안 업데이트, 소스 공개 전 확인할 절차

- 8월 29, 2026

Core Lightning 노드를 운영한다면 26.06.7로 가능한 한 빨리 올리되, 내려받은 바이너리의 체크섬과 유지관리자 서명을 먼저 확인하는 것이 현재의 직접 답 입니다. 2026년 8월 28일 공개된 이번 보안 릴리스는 취약점 세부 내용과 소스 코드를 14일 동안 공개하지 않습니다. 소스 공개 전 바이너리를 설치하고 싶지 않다면 노드를 평소처럼 온라인에 둔 채 기다리기보다 --offline 으로 재시작해 피어 연결을 멈추는 선택지를 검토해야 합니다. 핵심 요약 Core Lightning 26.06.7은 여러 제보로 확인된 취약점을 고친 보안 릴리스입니다. 실제 공격이 진행 중이라는 공식 확인은 없지만, 세부 정보가 공개되는 약 2주 뒤에는 패치 차이를 분석한 공격 시도가 쉬워질 수 있습니다. 운영자는 설치 방식과 CPU 아키텍처를 확인한 뒤 공식 자산만 받고, SHA-256 체크섬과 GPG 서명을 검증하고, 재시작 후 버전·피어·채널 상태를 점검해야 합니다. 서명된 바이너리를 검증해 업데이트하거나, 소스 공개 전까지 노드를 오프라인으로 두는 두 운영 경로를 나타낸 그림입니다. Core Lightning 26.06.7에서 실제로 발표된 내용은 무엇인가 Core Lightning 26.06.7 공식 릴리스 는 여러 출처가 책임 있게 보고한 취약점들을 수정했다고 밝힙니다. 다만 취약점 종류, 영향받는 기능, 공격 조건과 심각도는 아직 공개하지 않았습니다. “취약점이 있다”는 사실과 “내 노드가 실제로 공격받았다”는 판단은 같은 말이 아닙니다. 현재 공식 자료만으로 특정 자금 탈취나 채널 손실 시나리오를 단정해서는 안 됩니다. 프로젝트는 소스 코드를 릴리스 후 14일 동안 보류합니다. 이유는 수정 전후의 코드를 비교해 공격 방법을 역으로 찾는 시간을 늦추고, 운영자에게 먼저 패치할 창을 주기 위해서입니다. 이 기간에는 Linux용 사전 빌드 바이너리와 서명된 매니페스트를 배포합니다. 소스가 공개되면 미리 매니페스트에 기록된 소스 압축 파일의 해시...

이 블로그 검색