시냅스

이 글은 EVM 계열을 기준으로 설명합니다. 하지만 핵심은 체인이 아니라 오프체인 시스템 설계입니다.온체인 결제를 붙이는 순간, 결제 서비스는 분산 시스템이 됩니다.그리고 분산 시스템은 중복과 역전과 재시도와 지연을 기본 옵션으로 제공합니다. 0) 요약온체인은 최종 원장이고, 오프체인은 제품 상태 머신이다중복과 역전과 reorg까지 고려하려면 멱등성과 상태 전이를 강하게 설계해야 한다 1) 제가 처음 겪은 오프체인 착각 3가지제가 처음 web3를 접할 때 했던 오해는 이렇습니다.tx hash가 있으면 결제는 끝났다고 생각했다이벤트 로그를 한 번 읽으면 그게 진실이라고 생각했다실패하면 다시 보내면 된다고 생각했다현실은tx hash는 접수 번호에 가깝고이벤트는 되돌릴 수 있으며재시도는 비용과 부작용이 있다입..

이 글은 EVM 계열을 기준으로 설명합니다. 목표는 토큰 가격 얘기가 아니라, 결제와 정산 정책을 제품 언어로 번역하는 것입니다.web2 결제 개발자가 온체인 결제를 붙일 때 가장 크게 부딪히는 구간이 바로 여기입니다.0) 요약온체인 결제는 승인과 정산이 하나로 붙어 있고, 되돌리기와 차지백이 기본 기능이 아니다그래서 환불, 수수료, 분쟁 처리를 제품이 직접 설계해야 한다 1) 수수료는 누가 내나: 고객, 가맹점, 프로토콜web2 결제에서는 수수료 구조가 어느 정도 표준화되어 있습니다.하지만 온체인에서는 수수료가 두 갈래로 분해됩니다.네트워크 수수료: 블록 공간과 실행 자원 비용서비스 수수료: 제품이 부과하는 플랫폼 또는 사용료즉, 결제 1건의 비용은프로토콜 비용 + 서비스 비용입니다.그리고 중요한 차이..

이 글은 Ethereum 및 EVM 계열, 그리고 Solana의 SVM을 기준으로 설명합니다. 목표는 둘 중 어느 쪽이 더 낫다를 말하는 것이 아니라, 멀티체인 지원이 왜 난이도 폭증인지 운영 관점에서 이해하는 것입니다. 0) 요약EVM은 계정 nonce 기반 직렬화와 컨트랙트 호출 중심SVM은 트랜잭션에 명시된 계정 집합과 병렬 실행 중심같은 결제나 서명 기능을 만든다고 해도키 타입주소 표현서명 포맷트랜잭션 구조실패 모델인덱싱 방법이 전부가 달라집니다. 1) 서명부터 다르다: secp256k1 ECDSA vs Ed255191.1 EVM의 기본 서명보통 secp256k1 ECDSA해시 함수는 Keccak-256 계열을 많이 사용트랜잭션 서명은 chain id와 nonce를 포함한 특정 인코딩을 서명한다1..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. MEV는 한 문장으로 정리하면 이렇습니다.같은 트랜잭션 집합이라도 어떤 순서로 실행하느냐에 따라 추가 이익이 생기고, 그 이익을 두고 경쟁이 벌어진다web2 개발자에게는 이렇게 번역하는 편이 더 정확합니다.전 세계가 공유하는 커밋 로그에서, 커밋 순서를 두고 생기는 경제적 경쟁 1) MEV가 왜 생기나: 락 대신 전역 직렬화의 부작용EVM은 블록 안에서 트랜잭션을 순서대로 실행합니다.이 순서는 가치에 영향을 줍니다.DEX 가격은 먼저 실행한 거래에 의해 바뀐다청산 liquidation은 먼저 잡은 사람이 보상을 가져간다아비트리지 arbitrage는 먼저 맞춘 사람이 수익을 가져간다즉, 블록은 단순 저장이 아니라상태를 바꾸는 실행 순서표입니다..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 한 문장입니다.키를 어떻게 보관하고 서명할지의 선택이 곧 서비스 아키텍처와 운영 리스크를 결정한다이 글은 세 축을 다룹니다.핫 웜 콜드 지갑을 언제 어떻게 나누는가시드와 HD 지갑이 왜 기본값이 되었는가MPC가 무엇을 해결하고 무엇을 해결하지 못하는가 제가 처음 키 관리 얘기를 들을 때 했던 오해는 이렇습니다.지갑은 앱이고, 키는 그냥 파일 같은 것이다키를 잘 숨기면 끝이고, 보안은 암호학 문제다서비스는 어차피 서버가 처리하니 지갑은 하나면 된다현실은 이렇습니다.키는 비밀이면서 동시에 권한이다. 권한 설계가 곧 보안 설계다키를 온라인에 두면 운영 편의는 올라가지만 공격 표면도 같이 커진다지갑을 나누는 이유는 성능이 아니라..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 한 문장입니다.온체인 보안의 대형 사고는 취약한 코드 한 줄보다, 업그레이드와 권한과 운영 절차의 빈틈에서 더 자주 터진다이 글은 세 축을 다룹니다.업그레이드 프록시권한 설계운영 리스크와 사고 대응 제가 처음 업그레이드 가능한 컨트랙트를 접할 때 했던 오해는 이렇습니다.코드는 체인에 박히니 운영자가 바꿀 수 없다업그레이드를 넣으면 그냥 편해진다권한은 어드민만 안전하게 관리하면 된다현실은 이렇습니다.업그레이드 가능성을 넣는 순간, 코드 보안이 아니라 운영 보안이 주 리스크가 된다어드민 키가 뚫리면, 코드가 아무리 깔끔해도 끝난다업그레이드는 기능 배포이면서 동시에 자산 관리자 권한 행사다web2로 번역하면업그레이드 프록시는 D..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 한 문장입니다.스마트컨트랙트 보안 사고는 코드 버그라기보다 권한과 상태 변경 순서의 설계 실패로 시작한다이 글은 두 가지 전형을 먼저 익히는 데 집중합니다.재진입 reentrancy승인 allowance 기반 토큰 탈취 제가 처음 스마트컨트랙트를 접했을 때 인상은 이랬습니다.컨트랙트는 서버 코드처럼 한 번만 실행된다토큰은 송금이니까 잘못 보내면 끝이고, 승인은 별거 아니다보안은 감사 업체가 잡아줄 영역이다현실은 이렇습니다.컨트랙트 호출은 외부 컨트랙트로 다시 튈 수 있다승인 allowance는 장기 권한 위임이고, 실수하면 자동이체 권한을 넘겨준 것과 같다한번 배포된 코드는 운영자가 바로 고치기 어렵다web2로 번역하면재진..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 한 문장입니다.외부 데이터가 들어오는 순간, 블록체인은 더 이상 닫힌 세계가 아니며 신뢰 설계가 급격히 어려워진다 제가 처음 디파이와 온체인 결제를 볼 때 했던 오해는 이렇습니다.체인 위에서 돌아가니까 가격도 체인 위에 있을 것이다가격이 틀리면 그냥 데이터 오류다오라클은 API 한 번 호출하는 것과 비슷하다현실은 이렇습니다.체인은 외부 세계를 모른다가격은 외부에서 넣어야 하고, 그 순간 신뢰 경계가 생긴다오라클 문제는 데이터 정확도보다 조작 가능성과 가용성 실패가 더 위험하다 1) 오라클이란 무엇인가오라클은 체인 밖 정보를 체인 안에 반입하는 메커니즘입니다.자산 가격환율금리날씨 경기 결과 같은 이벤트KYC나 신용 점수 같은..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 이 한 문장입니다.web2 결제의 승인 매입 정산 프레임으로 온체인 포함 확정 정산을 맵핑하면 제품 의사결정이 쉬워진다 온체인 결제를 아래와 같이 이해했었습니다.블록에 들어가면 카드 결제의 승인 같은 것이다confirm은 정산 같은 것이다온체인은 환불이 없으니 정책이 단순해진다하지만 현실은 더 복잡합니다.승인과 정산이 분리되는 문제는 web2도 web3도 동일하다다만 web3는 실패 비용이 있고, 되돌림 reorg까지 고려해야 한다환불과 분쟁이 사라지는 게 아니라 구현 레이어가 바뀐다그래서 이 글은 결제 기획과 운영 언어로 체인을 번역합니다. 1) 카드 결제는 실제로 어떻게 굴러가나상세 네트워크는 카드사와 국가마다 다르지만..

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 이번 편의 목표는 한 문장입니다.즉시 UX를 주려면 오프체인이 필요하고, 최종 신뢰를 만들려면 온체인 커밋이 필요하다즉, 문제는 기술이 아니라 의사결정입니다.언제 무엇을 온체인에 커밋할 것인가제가 처음 이 문제를 접할 때 했던 오해는 이렇습니다.온체인이 느리면 그냥 오프체인으로 처리하면 된다오프체인으로 처리해도 언젠가 다 온체인에 올리면 된다배치 정산은 단순히 트랜잭션을 모아서 보내는 최적화다현실은 이렇습니다.오프체인은 승인 단계에 가깝고, 온체인은 정산 확정에 가깝다배치 정산은 비용 절감만이 아니라, 신뢰 경계를 설계하는 일이다서비스 안정성은 상태 머신과 리컨실리에이션에서 나온다web2 결제로 번역하면빠른 UX는 승인강한 신뢰는 정산둘 사..