HandsLog

개요 블록체인 기술에서 모든 것을 온체인(On-chain)으로 처리하는 것은 비효율적이거나 불가능한 경우가 많음 이때 오프체인 서명 검증(Off-chain Signature Verification)은 오프체인(서버)의 유연성과 온체인(컨트랙트)의 신뢰성을 결합하는 강력한 해결책이 됨 쉽게 비유하자면, 클럽 매니저(서버)가 VIP 손님(사용자)에게만 특별한 싸인이 담긴 입장권(서명)을 발급하고, 입구의 가드(스마트 컨트랙트)는 그 싸인만 확인하고 들여보내는 것과 같음 가드는 매번 매니저에게 연락할 필요 없이, 위조되지 않은 싸인인지 확인만 하면 됨 이 글에서는 오프체인 서명 검증이 무엇인지, 어떤 용어들이 사용되는지, 그리고 가장 중요하게는 어떤 원리로 동작하는지 상세히 알아봄 ...

개요 블록체인 서비스에서 사용자가 겪는 가장 큰 장벽 중 하나는 단연 가스비(Gas Fee)임 아무리 좋은 서비스를 만들어도, 사용자가 지갑에 가스비로 쓸 코인(ETH 등)을 보유하고 있어야 한다는 점은 대중화를 가로막는 결정적인 요인임 이 문제를 해결해 사용자가 가스비 걱정 없이 서비스 핵심 가치에만 집중하게 만드는 것, 즉 가스리스 트랜잭션(Gasless Transaction)을 구현하는 것이 이번 개발의 최종 목표였음 zkSync Era는 이를 위해 페이마스터(Paymaster)라는 강력한 시스템을 제공함. 페이마스터는 서비스 제공자 같은 제3자가 사용자를 대신해 트랜잭션 수수료를 지불할 수 있게 해주는 스마트 컨트랙트임 ...

SSE(Server-Sent Events)란 무엇인가 SSE는 Server-Sent Events의 약자로, 서버가 클라이언트로 실시간 데이터를 단방향으로 푸시(push)할 수 있게 해주는 웹 기술임 클라이언트가 먼저 요청을 보내고 서버는 그 연결을 끊지 않은 채, 새로운 데이터가 생길 때마다 지속적으로 응답을 보내는 방식임 주로 실시간 알림, 주식 시세 업데이트, 라이브 피드 등 서버에서 클라이언트로 일방적인 데이터 전송이 필요한 경우에 매우 유용함 SSE vs 웹소켓, 그리고 한계 SSE는 실시간 이벤트 전송에 유용하지만 만능은 아님. 웹소켓과 비교했을 때 명확한 장단점이 존재함 ...

개요 머클트리는 블록체인에서 거래 집합을 안전하고 효율적으로 요약·검증하기 위해 쓰이는 핵심 자료구조임 블록 헤더에 머클루트가 포함되는 이유는 블록 안의 모든 거래를 고정 크기 해시 하나로 대표해 무결성 확인과 경량 검증을 가능하게 하기 때문임 이 글은 머클트리의 구조와 동작 원리, 블록체인에서의 실무적 의미와 구현 주의사항까지 초보자도 이해할 수 있도록 상세히 설명함 핵심 개념과 구조 머클트리는 보통 이진 트리 형태로 구현함 거래들을 리프(leaf) 로 두고 인접 두 리프의 해시를 이어 붙여 부모 해시를 만들며 이 과정을 반복해 루트 해시를 얻음 해시 함수는 체인별로 다르며 비트코인은 더블 SHA‑256, 이더리움은 트라이 구조에서 Keccak‑256 을 사용함 최상단 해시를 머클루트(Merkle root) 라 부르며 크기는 해시 함수에 따라 고정됨 리프 수가 홀수일 때는 마지막 리프를 복제해 짝을 맞추는 방식이 일반적이며 비트코인은 이 규칙을 사용함 트리 깊이는 리프 수 N에 대해 ⌈log₂ N⌉ 에 비례하므로 대량의 거래를 효율적으로 요약할 수 있음 동작 원리와 장점 인접 노드 해시 H_left || H_right 를 순서대로 연결해 해시를 계산하고 이를 위로 올려가며 루트 해시를 얻음 무결성 검증 단일 거래가 바뀌면 해당 리프에서 루트까지의 모든 경로 해시가 바뀌어 변조를 즉시 탐지할 수 있음 효율적 포함 증명 특정 거래가 블록에 포함되었음을 증명하려면 그 거래와 경로상의 형제 해시들만 있으면 됨 필요한 해시 개수는 O(log N) 으로 작아 대역폭과 검증 비용이 작음 확장성 보조 리프가 1,000,000개여도 증명에 필요한 형제 해시는 약 20개 수준으로 32바이트 해시 기준 약 640바이트에 불과함 블록 헤더와 경량 노드(SPV) 비트코인 블록 헤더는 이전 블록 해시, 머클루트, 난스 등 합의 관련 메타데이터를 포함함 경량 노드(SPV)는 블록 전체가 아니라 헤더 체인만 받아 신뢰성을 확보하고, 개별 거래에 대해서는 풀노드로부터 머클 증명 을 받아 포함 여부를 검증함 이 방식은 모바일·임베디드 환경에서도 실사용이 가능하게 하는 기반이 됨 이더리움은 전통적인 이진 머클트리 대신 머클‑패트리샤 트라이(MPT) 를 사용해 거래·영수증·상태 루트를 헤더에 담아 유사한 목적을 달성함 구현 세부와 체인별 차이 비트코인 ...

개념/배경 Reverse Tabnabbing은 target="_blank"로 연 새 탭이 window.opener를 통해 기존 탭을 피싱 페이지로 바꾸는 기법을 말함 새 탭이 기존 탭에 대한 참조를 갖기 때문에 발생하며, 자바스크립트로 opener의 위치를 변경 가능함 예시 window.opener.location = 'https://cgn.example.com' 이 참조를 끊는 표준 방법은 링크에 rel=“noopener” 또는 rel=“noopener noreferrer"를 명시하는 것임 공격 시나리오 사용자가 cgm.example.com 접속 happy.example.com 링크 클릭 새 탭에서 happy.example.com 열림 → 스크립트가 기존 탭을 피싱 사이트로 이동시킴 window.opener.location='https://cgn.example.com' 기존 탭으로 돌아온 사용자는 세션 만료로 오인 후 자격증명 입력 피싱 페이지가 정보를 수집 후 원래 페이지로 리다이렉션 방어 전략 앵커 태그에 rel=“noopener” 최소 적용, 가능하면 rel=“noopener noreferrer” 적용 권장 noopener: 새 탭에서 window.opener가 null이 되어 기존 탭 제어 불가 noreferrer: 대부분 브라우저에서 opener 차단 + Referer 헤더 전송 차단 자바스크립트로 새 창을 열 경우 window.open(url, '_blank', 'noopener') 사용 고려 기존 코드 점검 시 target="_blank” 링크에 rel 값 누락 여부 정적 분석 또는 린트 규칙으로 검출 권장 주의 사항 일부 최신 브라우저는 target="_blank"에 대해 기본적으로 noopener를 적용하는 경향 있으나 브라우저·버전별 차이 존재, 명시적 rel 사용이 안전 noreferrer는 분석 도구에서 유입 경로 확인이 어려워질 수 있음, 트래픽 분석 요구가 있으면 noopener만 선택하는 운영 전략 고려 참고: noopener와 noreferrer noopener: 새 탭의 Window.opener를 제거하여 원탭 조작 방지 noreferrer: Referer 헤더 차단, 대부분 환경에서 opener 제거 동작 동반 마무리 target="_blank"는 편리하지만 기본 동작만으로는 탭 간 참조가 남아 공격면 존재 모든 외부 링크에 rel=“noopener” 또는 필요에 따라 rel=“noopener noreferrer"를 일관 적용하는 것이 가장 단순하고 효과적인 방어 전략임 ...

개요 즉시 실행 함수 표현 IIFE(Immediately Invoked Function Expression)는 정의 직후 바로 호출되는 함수 패턴을 의미함 ES5 시기에는 클래스나 표준 모듈이 없어 전역 스코프 오염 방지와 초기화 코드 캡슐화에 널리 사용됨 ES6 이후에는 모듈 export/import가 기본 선택지이나, 독립 실행 초기화 코드, 라이브러리 래퍼, 폴리필 등에서는 여전히 유효한 도구임 함수 선언과 함수 표현의 차이 함수 선언 Function Declaration 선언이 호이스팅되어 해당 스코프의 시작 시점에 바인딩됨 선언 이전 호출 가능 함수 표현 Function Expression ...

개요 LINQ의 주요 연산자를 개념과 동작 관점으로 정리함. 각 연산자가 입력 시퀀스를 어떻게 변환하는지, 결과 크기와 순서를 어떻게 보장하는지, 즉시 실행 여부와 예외 동작은 무엇인지에 초점을 둠. 설명은 가능한 한 단순한 정의와 함께 주의점 중심으로 구성함 기본 변환과 필터 Select 한 요소를 다른 형태로 사상하는 투영 연산 입력 개수 보존, 출력 개수는 입력과 동일 프로퍼티 선택, 새 익명 객체 구성, 스칼라 변환 등에 사용 Where 조건식이 true인 요소만 통과시키는 필터링 연산 결과 개수는 입력 이상이 될 수 없으며 같거나 더 작거나 빈 시퀀스가 될 수 있음 술어 평가가 false면 요소 제외, 지연 실행으로 조건이 충족될 때만 열거 진행 SelectMany ...

개요 HTML 문서를 구성하는 요소들을 카테고리별로 묶어 핵심 의미와 사용 시점을 빠르게 파악하는 참고서 시맨틱 마크업과 접근성, SEO에 직접적인 영향을 주는 요소 위주로 정리 전체 목록과 세부 제약은 MDN 문서를 최종 기준으로 확인 권장 메인 루트와 구획 루트 html: 문서 루트 요소, 모든 요소의 조상이어야 함 body: 문서 본문 루트, 문서 내 하나만 존재 문서 메타데이터 head: 기계가 읽는 문서 메타데이터 컨테이너 base: 문서 내 상대 URL의 기준 URL 지정, 문서당 하나만 허용 link: 외부 리소스와의 관계 선언, CSS 연결과 파비콘 등 meta: title, style 등으로 표현 불가한 메타데이터 표현 style: 문서 범위의 스타일 선언 title: 브라우저 탭에 표시되는 문서 제목, 텍스트만 허용 콘텐츠 구획 문서 구조와 내비게이션에 쓰이는 시맨틱 컨테이너 ...

개요 Node.js에서 console.log로 객체를 찍다 보면 [Object], [Array]로 축약돼 상세 구조가 보이지 않는 경우가 많음 원인은 console.log가 내부적으로 util.inspect를 사용하고, 기본 depth가 2이기 때문임 아래에서 동작 방식과 옵션, 실무에서 흔히 하는 설정을 정리함 console.log가 [Object]로 축약되는 이유 console.log는 객체를 문자열로 만들 때 util.inspect를 사용함 기본 동작은 depth 2까지 펼치고 그 이후는 축약 표시 0단계 예시 { args: [Object] } 1단계 예시 { args: { take: 5, orderBy: [Array], where: [Object] } } 2단계 예시 { args: { take: 5, orderBy: [ [Object] ], where: { userId: 123 } } } 3단계 예시 { args: { take: 5, orderBy: [ { createdAt: 'desc' } ], where: { ... } } } 기본 depth가 2이므로 3단계 이상 중첩된 객체는 [Object], 배열은 [Array]로 축약 표시됨 util.inspect 간단 소개 util.inspect는 node:util 모듈에 있는 함수로, JS 값을 사람이 읽기 좋은 문자열로 직렬화하는 유틸리티 console.log(obj)는 실질적으로 util.inspect(obj, { depth: 2, colors: false })와 유사하게 동작함 ...

개요 새너티 테스트와 스모크 테스트는 릴리스 안정성을 빠르게 가늠하기 위한 얕은 검증 활동. 용어가 비슷하지만 주체와 시점, 방법이 다름. 헷갈리면 품질 게이트가 흐려짐 개념과 정의 Sanity Testing 새로 추가된 기능이나 수정된 버그가 의도대로 동작하는지 개발자가 빠르게 확인하는 탐색형 확인. 사전에 문서화된 테스트 케이스 없이 핵심 경로 위주 확인 Smoke Testing 시스템의 주요 기능에 대해 미리 정의된 테스트 케이스의 부분 집합을 실행해 빌드가 더 깊은 테스트를 진행할 수 있을 만큼 건강한지 확인. 전자 기판에 전원을 넣어 연기가 나는지 보는 관행에서 유래 동작과 시점 주체 새너티는 대부분 개발팀 중심. 스모크는 개발팀 또는 검증팀 수행 대상 새너티는 신규 기능과 버그 수정 범위. 스모크는 로그인 결제 등 핵심 기능 전반 시점 새너티는 빌드 또는 릴리스 전 변경 단위 확인. 스모크는 빌드 후 통합본에서 수행 방법 새너티는 자유 탐색형 확인. 스모크는 사전 정의된 케이스 집합 실행 간단 예시 로그인 기능을 추가했다면 개발자는 로컬이나 스테이징에서 정상 로그인 실패 케이스 리그레션을 빠르게 새너티로 본다. 이후 통합 빌드가 배포되면 스모크에서 로그인 회원가입 대시보드 진입 등 핵심 플로우가 최소 기준을 충족하는지 본다. 하나라도 막히면 빌드 불합격 처리 ...