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) 를 사용해 거래·영수증·상태 루트를 헤더에 담아 유사한 목적을 달성함 구현 세부와 체인별 차이 비트코인 ...

개요 Dockerizing은 Docker 컨테이너를 사용해 애플리케이션을 패키징하고 배포하고 실행하는 일련의 과정 코드와 런타임, 의존성, 설정을 이미지로 고정하여 환경 차이와 배포 리스크를 낮추는 것이 목적 핵심 개념 Image: 애플리케이션과 런타임, 의존성, 설정을 포함한 불변 아티팩트 Container: 이미지를 실행한 격리된 프로세스 단위 Dockerfile: 이미지를 만들기 위한 선언형 스펙 Registry: 이미지를 저장하고 배포하는 원격 저장소 동작 흐름 빌드 단계 Dockerfile 작성 후 docker build 실행해 이미지 생성 태그 전략 수립 필요 ex) app:1.2.3, app:stable, app:commit-hash 배포 단계 레지스트리에 docker push 환경별 레지스트리 또는 네임스페이스 구분으로 충돌 방지 실행 단계 docker run으로 컨테이너 기동, 포트 매핑과 환경 변수 주입 로그는 표준 출력으로 수집, 상태 점검을 위해 헬스체크 설정 권장 업데이트와 롤백 불변 이미지와 태그 기반 배포로 롤백 단순화 레지스트리 보존 정책으로 이력 관리 간단 예시 최소 Dockerfile 스니펫 FROM alpine:3.19 WORKDIR /app COPY . . CMD ["sh", "-c", "echo hello"] 로컬 빌드와 실행 docker build -t app:local . docker run --rm -p 8080:8080 app:local주의와 베스트프랙티스 최소 베이스 이미지 선택으로 공격면과 이미지 크기 축소 레이어 캐시 고려해 변경 빈도 낮은 명령을 상단에 배치 멀티스테이지 빌드로 빌드 타임 도구를 런타임 이미지에서 제거 비밀정보는 이미지에 포함하지 않고 시크릿 관리 도구 또는 런타임 주입 사용 컨테이너 리소스 제한 설정으로 노이즈 네이버 이슈 완화 개발과 운영 환경 간 설정 차이는 환경 변수와 명시적 구성으로 관리 보안 스캔과 베이스 이미지 업데이트 자동화로 취약점 대응 마무리 Dockerizing은 애플리케이션을 이미지로 표준화해 이식성과 재현성을 확보하고 배포 파이프라인 단순화에 기여함 핵심은 선언적 스펙으로 빌드하고 불변 이미지를 레지스트리로 배포한 뒤 태그와 자동화를 통해 일관되게 실행하는 것 작게 빠르게 안전하게의 원칙을 적용하면 운영 효율과 신뢰도 상승 ...

개념/배경 NaN은 JavaScript 숫자 타입의 특별한 값으로 계산 불능을 의미함 NaN은 어떤 값과도 같지 않으며 자기 자신과도 같지 않음 동등 비교 연산으로는 판별 불가 올바른 판별 방법 Number.isNaN 값이 실제 NaN인지만 검사, 타입 강제 변환 수행 안 함 isNaN 전달된 값을 숫자로 변환한 뒤 검사, 문자열 등에서 오탐 가능 x !== x는 오로지 NaN에서만 참이 되는 성질 활용 가능 주의할 점 외부 입력이 문자열인 경우 숫자로 명시 변환 후 Number.isNaN으로 확인 권장 빈 문자열 Number(’’)는 0, parseInt(’’)는 NaN 반환 차이 주의 0/0, Math.sqrt(-1) 같은 계산에서 NaN 발생 가능 동등 비교나 switch 키로 NaN을 식별하려 하지 말 것 ...

개념/배경 운영 중 특정 데이터베이스에서 대기나 블로킹이 의심될 때, 현재 걸린 트랜잭션 락을 직접 확인하는 것이 우선임 SQL Server의 동적 관리 뷰 sys.dm_tran_locks는 활성 잠금 정보를 제공하며 데이터베이스 단위로 필터링 가능 사용법/예시 아래 쿼리로 대상 DB에 설정된 잠금 목록 조회 SELECT * FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID('MY_DB')요점 컬럼 참고 request_session_id: 잠금 보유 또는 대기 세션 ID resource_type, resource_associated_entity_id: 잠금 대상 리소스 식별 request_mode: 잠금 모드 (S, X 등) request_status: GRANT 또는 WAIT 상태 추가 확인 포인트 블로킹 체인 파악 필요 시 sys.dm_exec_requests, sys.dm_os_waiting_tasks와 조합하여 대기 중인 세션과 차단 세션 상관분석 권장 식별된 차단 세션은 영향 분석 후 종료 여부 판단 ...

개요 CSS 사용자 지정 속성(CSS Variables, Custom Properties)은 재사용 가능한 값을 선언하고 문서 전반에서 참조하기 위한 메커니즘 반복되는 색상, 간격, Z-index 같은 값을 의미 있는 이름으로 관리해 전역 치환 리스크를 줄이고 테마 전환 같은 요구에 유연하게 대응 가능 사용자 지정 속성은 일반 CSS 규칙에 포함되어 캐스케이딩과 상속의 영향을 받음 핵심 개념 표기 규칙: 이름은 두 개의 대시로 시작, 예) –main-color 대소문자 구분: –my-color와 –My-color는 서로 다른 속성 참조 방식: var(–name) 형태로 값 참조 기본값 지원: var(–name, fallback) 형태로 값이 없을 때 대체값 지정 가능 속성 값 위치에서만 사용 가능, 선택자나 미디어 쿼리 조건, 속성 이름에는 사용 불가 동작 원리와 스코프 사용자 지정 속성은 선언된 규칙의 선택자 범위에만 유효 상속 특성 보유, 상위에서 선언하면 하위에서 참조 가능 :root에 선언하면 문서 전역 범위의 기본값으로 동작 동일한 변수 이름을 더 구체적인 선택자나 조건에서 재정의하면 캐스케이드에 따라 해당 범위에서 우선 적용 사용법과 짧은 예시 전역 선언과 기본 참조 ...

개요 파이썬 변수와 함수 인수 전달 방식을 정리함 주요 키워드 세 가지 정리 call by value call by reference call by object reference (aka call by sharing) 헷갈리는 포인트는 call by reference와 call by object reference의 차이임 파이썬에서 실제로 일어나는 바인딩과 가변성의 조합으로 이해 필요 호출 방식 개념 정리 Call by Value 인수 전달 시 값의 복사 전달 함수 내부에서 인자를 변경해도 호출자 쪽 원본에는 영향 없음 Call by Reference 인수 전달 시 변수 자체를 참조로 전달하는 모델 함수 내부 변경이 호출자 변수에 그대로 반영됨 특정 언어에서만 엄밀히 지원되는 개념이며, C는 포인터를 값으로 전달해 유사 동작을 만들 수 있으나 언어 차원의 call by reference와는 구분 필요 Java는 참조 자체를 값으로 전달하므로 call by reference가 아님에 주의 ...

개요 브라우저에서 API 호출이 분명 성공한 것 같은데, 콘솔에는 CORS 에러가 뜨는 상황 자주 마주함 문제의 본질은 서버가 망가진 게 아니라 브라우저의 보안 정책에 의해 응답 사용이 차단된 것임 CORS는 차단을 풀기 위한 협상 절차이자 규칙 세트이며, 정확히 이해하면 재현과 해결이 쉬워짐 핵심 개념 Origin 정의 Origin = scheme + host + port 조합 세 요소 중 하나라도 다르면 서로 다른 출처로 판단 SOP(Same-Origin Policy) 동일 출처 간 상호작용 허용, 교차 출처는 기본 차단하는 브라우저 보안 정책 XSS, CSRF 등 교차 사이트 공격 리스크 완화 목적 출처 비교와 차단 판단 주체는 서버가 아니라 브라우저 예외적으로 허용되는 리소스 ...