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

개요 N+1 쿼리 문제는 ORM에서 자주 발생하는 성능 이슈로, 기본 쿼리 1회 이후 연관 데이터를 접근하는 시점마다 추가 쿼리가 N회 발생하는 상황을 의미함 Django ORM은 기본적으로 lazy-loading 전략을 사용하므로 관계 필드 접근 시점에 쿼리가 실행됨 이 글에서는 N+1의 동작 맥락과 lazy-loading의 특성, 그리고 select_related와 prefetch_related로 N+1을 예방하는 방법을 정리함 N+1 쿼리 문제 예시 방문 기록 Visitor와 방문자 정보 Person이 외래키로 연결된 상황 가정 visitors = Visitor.objects.filter(visit_date__year=2022) for v in visitors: print(v.person.name, v.visit_date)위 코드는 다음 흐름으로 동작함 ...

배경과 문제 정의 맥을 초기화하고 Homebrew cask로 Docker Desktop 설치 후 docker compose가 동작하지 않음 터미널에 docker: ‘compose’ is not a docker command 메시지 출력, buildx도 동일 증상 재설치와 초기화를 반복했지만 변화 없음 환경 macOS Ventura 13.0.1 Apple Silicon M1 Docker 20.10.21 build baeda1f 원인 가설 Docker Desktop에 포함된 CLI plugin 디렉터리가 docker가 검색하는 경로와 연결되지 않음 compose와 buildx는 독립 바이너리가 아니라 CLI plugin으로 배포됨 해결 CLI plugin 디렉터리에 심볼릭 링크 추가 ...

개요 소켓과 전통 RPC, 그리고 REST를 거쳐 gRPC가 등장한 배경과 핵심 특성 정리 HTTP/2와 Protocol Buffers를 결합한 gRPC의 구조, Proto 파일 작성 규칙, 그리고 실제 인코딩 원리까지 흐름 중심으로 정리 후반부에는 인증과 장애 상황에서의 동작 특성, 도입 적합 영역 요약 등장 배경 Server-Client 모델의 확산 배경 초기 모놀리식 메인프레임 시대에는 네트워크 통신 중요도 낮음 소형 컴퓨터와 워크스테이션 보급으로 기능 분산 필요성 증가 네트워크 계층 표준화 진행과 함께 서버 간 통신이 핵심 과제로 부상 ...

개요 DNS TTL은 레코드가 캐시로 유지되는 시간의 기준값으로 초 단위 설정값임. 권한 네임서버가 응답에 TTL을 포함하고, 재귀 리졸버와 클라이언트가 이 시간 동안 결과를 기억함. TTL이 만료되면 다시 질의가 발생함 핵심 개념 TTL Time To Live DNS 응답을 브라우저나 재귀 DNS 서버가 얼마 동안 캐시할지 정하는 값 예 TTL이 300이면 해당 레코드는 5분간 캐시 유지, 이후 재질의 발생 부존재 응답 NXDOMAIN 역시 SOA 설정에 따라 일정 시간 캐시됨 왜 중요한가 TTL이 짧으면 변경 사항이 빠르게 반영됨 트래픽 변화 대응 용이 대신 DNS 요청 수 증가로 지연과 비용 증가 가능 TTL이 길면 질의 수가 줄어 효율적이고 안정적임 캐시 적중률 상승 대신 변경 반영이 느림 권장 TTL 값 가이드 일반 웹사이트 300600 510분 트래픽 변화가 잦은 API 60~300 안정적이고 변경이 드문 서비스 360086400 1시간하루 레코드 변경 직전 예 이관 60 이하로 낮춰 사전 준비 참고 사항 ...

개요 CSS에서 선택자는 DOM에서 스타일을 적용할 대상 요소 집합을 정의하는 식 컴포넌트 스코프와 일관된 스타일링, 유지보수 비용에 직접 영향 핵심 유형과 매칭 원리, 명시도와 베스트프랙티스 중심 요약 핵심 개념 타입 선택자 tag 특정 태그 타깃 클래스 선택자 .class 재사용 가능한 스타일 단위에 적합 아이디 선택자 #id 고유 요소 타깃, 명시도 높음 속성 선택자 [attr], [attr=value], [attr*=substr] 속성 값 기반 매칭 가상 클래스 :hover, :focus, :active, :not(), :is() 상태나 집합 표현 가상 요소 ::before, ::after 논리적 하위 요소 생성 결합자 A B 하위, A > B 자식, A + B 인접 형제, A ~ B 일반 형제 관계 표현 그룹 A, B 동일 스타일의 대상 묶음 최신 선택자 :has() 부모가 특정 자식을 가질 때 매칭, 브라우저 지원 범위 확인 권장 동작 원리와 명시도 브라우저는 각 규칙의 선택자를 DOM 노드에 대조해 매칭된 규칙을 수집 후 명시도와 소스 순서로 충돌 해결 명시도 계산 규칙 요약 ...

개요 Django의 미들웨어는 요청과 응답을 전역적으로 가로채어 공통 로직을 삽입하는 경량 플러그인 시스템임. 입력 또는 출력의 전역 수정이 필요할 때 사용함 미들웨어 시스템과 순서 settings.py의 MIDDLEWARE 리스트에 등록된 항목을 기준으로 동작함. 요청 단계는 위에서 아래 순서로 통과, 응답 단계는 아래에서 위 순서로 역순 통과. 순서가 기능적 의존성과 직결되므로 중요함. 예시로 AuthenticationMiddleware는 세션을 읽기 때문에 SessionMiddleware 이후 배치 필요 커스텀 미들웨어 만들기 미들웨어는 함수 기반 또는 클래스 기반 중 하나로 작성. get_response를 호출하면 다음 미들웨어 혹은 최종 view로 제어가 넘어가며, 반환 이후 구간이 응답 후 처리 지점이 됨 ...