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

레디스가 싱글스레드라서 BullMQ에서 job data가 커지면 Redis가 터진다고 단순화해서 말하는 경우가 많음 하지만 실제로는 Redis가 큰 payload 처리 때문에 막히고, 그 지연이 메모리와 네트워크 문제로 이어지며 타임아웃이나 OOM 같은 연쇄 문제로 번지는 쪽이 더 큼 job data가 커질 때 Redis에서 바로 벌어지는 일 1) 이벤트루프가 큰 값 때문에 오래 점유 BullMQ는 job을 만들 때 job data를 보통 Redis에 문자열이나 JSON 형태로 저장함 job data가 커지면 쓰기와 조회 모두에서 처리해야 하는 바이트가 늘어남 SET이나 HSET 같은 쓰기, HGET 같은 조회가 한 명령당 처리해야 하는 바이트를 키움 ...

개요 oh-my-codex, oh-my-claudecode, claw-code를 묶어 보면 에이전트형 코딩 도구는 모델 자체보다 “운영체제 같은 orchestration layer”로 확장된다는 결론으로 수렴한다. 여기서는 Codex CLI와 Claude Code가 skill, agent, sub-agent, tmux worker, PR review, verification loop 같은 자동화를 붙일 수 있는 이유와 바닥 런타임 구조를 층으로 정리한다 핵심은 모델 튜닝이 아니라 다음 조합으로 행동을 바꾸는 접근이다 상위 지시문 skill, prompt, agent 카탈로그 상태 파일과 산출물 디렉터리 hook 또는 세션 부트스트랩 서브에이전트와 tmux worker 검증, 리뷰, 커밋, PR 프로토콜 에이전트형 코딩 도구의 6개 층 Codex CLI, Claude Code, claw-code 같은 도구는 보통 아래 6개 층으로 이해할 수 있다 ...

개념을 먼저 레이어로 분리 HTTP에서 인증을 얘기할 때는 보통 아래 4축으로 보면 정리가 빠름 자격 증명을 매 요청에 직접 보내는 방식 서버가 저장한 상태를 식별자로 조회하는 방식 토큰 자체를 검증하는 방식 외부 인증 또는 권한 위임 프레임워크를 이용하는 방식 조금 더 구조적으로 나누면 다음처럼 분류 가능함 Credential-based Basic Auth Digest Auth API Key Client Certificate mTLS Stateful Identifier-based Session ID Opaque Token Stateless Token-based JWT PASETO 기타 signed token Authentication / Authorization Framework OAuth 2.0 OpenID Connect SAML HTTP 기반 웹 SSO 맥락 여기서 중요한 건 인증과 인가, 전달 메커니즘이 섞여서 헷갈리는 경우가 많다는 점임 ...

컨테이너에 CPU와 메모리를 얼마나 줄지 정하는 설정은 크게 두 가지입니다. request는 최소 보장을 위한 값이고 limit은 최대 상한선입니다. 이 둘을 어떻게 설정하느냐에 따라 스케줄링과 런타임 동작이 달라집니다 Request는 최소 이만큼은 보장해줘 스케줄러는 pod를 노드에 배치할 때 request를 기준으로 자원을 예약합니다. 즉 이 컨테이너는 최소 이만큼 필요하다는 의미이며, 노드에 request만큼의 여유가 없으면 해당 노드에는 올라가지 못합니다. 또한 request만큼의 자원은 다른 pod가 아무리 바빠도 최소한으로는 확보된다고 이해하면 됩니다 Limit은 최대 이만큼까지만 써라 limit은 컨테이너가 넘을 수 없는 상한입니다. limit을 초과하려고 하면 ...

배경 ES6 이후 이터러블(iterable)이나 유사 배열 객체(array-like object)를 실제 배열로 변환하는 상황은 매우 흔합니다. 대표적으로 [...iterable](전개 구문, Spread Syntax)과 Array.from() 메서드를 사용합니다. 두 방식은 대부분의 경우 동일하게 동작하는 것처럼 보이지만, 동작 원리와 지원 범위에 명확한 차이가 있어 상황에 맞게 선택해야 합니다. 핵심 차이점 두 방식의 가장 큰 차이는 변환할 수 있는 소스 객체의 타입입니다. 전개 구문 ([...iterable]) 오직 이터러블 프로토콜을 따르는, 즉 Symbol.iterator 속성을 가진 객체에만 사용할 수 있습니다. NodeList가 이터러블인 최신 브라우저 환경에서는 문제없이 동작하지만, 그렇지 않은 환경에서는 TypeError가 발생합니다. ...

Cron, Crontab, Cronjob 유닉스 계열 운영체제에서 특정 작업을 정해진 시간에 자동으로 실행하려면 Cron을 사용합니다. Cron은 백그라운드에서 동작하는 데몬(daemon)이며, 스케줄링 설정을 바탕으로 명령어나 스크립트를 실행합니다 Cron: 시간 기반 잡 스케줄러(Job Scheduler)로, 특정 시간에 작업을 실행하는 시스템 데몬 Crontab: ‘Cron Table’의 약자로, Cron 작업의 목록과 실행 시간을 정의하는 설정 파일 또는 해당 파일을 다루는 명령어 Cronjob: Crontab에 등록되어 주기적으로 실행되는 개별 작업 이 글에서는 Cronjob을 정의하는 Cron 표현식(Cron Expression)의 구조와 문법을 정리합니다 ...