Blockchain

이더리움 Glamsterdam 업그레이드: ePBS와 BAL, 전체 EIP와 달라지는 운영

이더리움 Glamsterdam 업그레이드: ePBS와 BAL, 전체 EIP와 달라지는 운영

Glamsterdam은 이더리움 L1의 처리 용량을 늘리기 위해 블록을 만드는 절차와 받은 블록을 검증하는 절차를 함께 바꾸는 업그레이드입니다. ePBS는 블록 제안자와 빌더 사이의 약속·공개·지급을 프로토콜 안에서 처리하고, BAL은 블록 실행 중 접근한 상태와 트랜잭션별 변경값을 전달해 수신 노드가 읽기와 검증을 병렬화하도록 돕습니다. 가스 재조정과 네트워크 개선도 이 목표를 뒷받침합니다. 다만 모든 거래의 수수료 인하나 일정한 TPS를 보장하는 변경은 아닙니다. EIP-7773이 전체 범위를, EIP-7732와 EIP-7928이 두 핵심 메커니즘을 정의합니다.

더 보기
Canton Daml로 토큰 전송하기: Solidity와 상태·권한 비교

Canton Daml로 토큰 전송하기: Solidity와 상태·권한 비교

Alice가 가진 토큰 100 단위를 Bob에게 모두 보내면, 다음에 그 100 단위를 쓸 수 있는 사람은 Bob입니다. Solidity 예제는 주소별 잔액을 갱신하고, Canton에서 실행할 Daml 예제는 Alice의 보유 계약을 소비한 뒤 Bob의 보유 계약을 만듭니다. 같은 전송 결과를 서로 다른 상태와 권한으로 표현합니다.

더 보기
Besu 이해하기: 이더리움 실행부터 은행의 토큰 결제까지

Besu 이해하기: 이더리움 실행부터 은행의 토큰 결제까지

Besu는 스마트 계약을 실행하고 그 결과를 검증·저장하는 Java 기반 Ethereum 클라이언트입니다. 은행은 이 소프트웨어로 예금 토큰과 은행 간 결제 자산을 함께 처리하는 원장을 구성할 수 있습니다. Ethereum 메인넷의 실행 노드로도 쓰입니다. 어느 쪽이든 실행 기술은 공유하지만, 돈의 발행자와 원장을 확정하는 주체는 네트워크마다 달라집니다. Besu 공식 문서

더 보기
Canton Network 이해하기: 금융 프라이버시와 원자적 결제, 기관 도입 현황

Canton Network 이해하기: 금융 프라이버시와 원자적 결제, 기관 도입 현황

증권을 산다는 행위에는 여러 원장이 관여합니다. 거래소나 거래 플랫폼에는 체결 기록이 남고, 수탁기관에는 증권 보유 기록이 남습니다. 지급을 담당하는 은행은 현금 장부를 따로 관리합니다. 서로 다른 기관이 같은 거래를 각자의 시스템에 기록하므로, 거래 후에는 금액과 권리, 처리 상태를 다시 맞추는 대사 작업이 필요합니다. 모든 기관이 하나의 공개 장부를 사용하면 단순해 보이지만 고객 잔액과 거래 전략까지 공개할 수는 없습니다.

더 보기
Glamsterdam의 새 가스 모델: EIP-8037 상태 가스, EIP-8038 접근 비용, EIP-2780 기본 가스

Glamsterdam의 새 가스 모델: EIP-8037 상태 가스, EIP-8038 접근 비용, EIP-2780 기본 가스

Glamsterdam의 세 가스 제안은 새 상태를 영구 저장하는 비용과 기존 상태를 갱신하는 비용을 올리고, 작업이 적은 일부 트랜잭션의 기본 비용을 낮춥니다. 명세상 새 콜드 스토리지 슬롯에 쓰면 실행 가스 12,100에 상태 가스 97,920이 붙고, 기존 슬롯의 트랜잭션 시작 값이 0이 아니고 콜드 상태에서 그 값과 다르게 처음 바꾸면 실행 가스 12,100이 들며 상태 가스는 들지 않습니다. 두 비용 모두 트랜잭션의 gasLimit 하나로 충당하지만 gasleft()는 별도 상태 가스 리저버를 보여 주지 않습니다. 이 숫자는 명세의 구성 비용이며 Solidity 함수 전체의 측정값이나 메인넷 적용 공지가 아닙니다. EIP-8037, EIP-8038, EIP-2780이 이 변경을 함께 정의합니다.

더 보기
A2A(Agent-to-Agent) 프로토콜: 에이전트 간 협업 표준과 결제 레이어의 접점

A2A(Agent-to-Agent) 프로토콜: 에이전트 간 협업 표준과 결제 레이어의 접점

A2A(Agent2Agent)는 따로 운영되는 에이전트에 일을 맡기고, 진행 상태와 결과를 받는 방법을 표준화합니다. 요청자는 Agent Card로 상대의 기능·접속 주소·인증 조건을 확인하고, 오래 걸리는 일은 Task로 추적합니다. MCP는 각 에이전트가 도구와 데이터를 사용하는 연결을 담당하며, 구매 승인이나 결제 정산은 AP2·x402 같은 별도 규약이 맡습니다. A2A로 협업하는 데 블록체인이나 지갑은 필요하지 않습니다. A2A 명세, MCP와의 역할 분담

더 보기
KYA(Know Your Agent): AI 에이전트 신원 검증, 표준 경쟁과 온체인 실태

KYA(Know Your Agent): AI 에이전트 신원 검증, 표준 경쟁과 온체인 실태

AI 에이전트가 신원 인증서나 온체인 등록 번호를 제시해도, 그 사실만으로 결제나 데이터 접근을 허용해서는 안 됩니다. 어느 에이전트인지, 요청자가 그 신원을 통제하는지, 지금 하려는 행동을 위임받았는지, 과거 평가를 얼마나 믿을지는 서로 다른 확인입니다. KYA(Know Your Agent)는 이런 확인을 묶어 부르는 이름입니다. ERC-8004는 식별자와 공개된 신뢰 신호를 제공하고, Visa TAP이나 신원 검증 업체는 요청·조직·사람을 확인하는 다른 방식을 제공합니다. 최종 접근 결정은 서비스를 제공하는 쪽에 남습니다. ERC-8004 명세와 Trulioo의 제품 설명도 각각 등록과 검증이 보장하는 범위를 제한합니다.

더 보기
비트코인과 이더리움, 양자 컴퓨터는 정말 위협일까

비트코인과 이더리움, 양자 컴퓨터는 정말 위협일까

양자 컴퓨터는 비트코인과 이더리움의 서명을 위조할 수 있는 장기적 위협입니다. 다만 2026년 10월 16일(KST) 확인한 공개 연구는 실제 secp256k1 개인키 복구 시연이 아니라, 미래의 오류 수정 양자 컴퓨터에 필요한 자원을 계산한 결과입니다. 위험을 가르는 조건은 공개키가 얼마나 오래 노출되는지, 공격 계산이 얼마나 걸리는지, 그 전에 서명과 권한을 전환할 수 있는지입니다. 비트코인의 방어안은 아직 제안 단계이고 이더리움도 계정·합의·데이터 계층을 함께 바꾸는 작업을 진행 중입니다. 자원 추정 논문, BIP-360, 이더리움 재단의 전환 계획

더 보기
Apify x402와 Coinbase 지갑 심층편: 에이전트가 웹 자동화 도구를 직접 사는 구조

Apify x402와 Coinbase 지갑 심층편: 에이전트가 웹 자동화 도구를 직접 사는 구조

웹 스크래핑 플랫폼 Apify가 x402 결제 지원을 발표했다. AI 에이전트가 Apify 계정도 API 키도 없이 Base 체인의 USDC로 결제하고, 2만 개가 넘는 Actor를 실행할 수 있다는 내용이다. Apify는 기존 x402 생태계를 약 2,000개 엔드포인트 규모로 보고, 이번 통합으로 결제 가능한 도구 표면이 약 10배 커졌다고 설명한다.

더 보기
AI 에이전트 상거래와 조율: ERC-8183, ERC-8226, ERC-8001, ERC-8041

AI 에이전트 상거래와 조율: ERC-8183, ERC-8226, ERC-8001, ERC-8041

이전 글에서 다룬 ERC-8004/8126/8196은 AI 에이전트의 신원 등록, 보안 검증, 정책 실행이라는 세 계층을 정의한다. 에이전트를 식별하고, 위험도를 평가하고, 소유자가 허용한 범위 안에서만 거래를 실행하게 만드는 기반이다. 여기까지가 답하는 질문은 하나다. “이 에이전트를 믿고 내 대신 움직이게 해도 되는가.”

더 보기
Chainlink CCIP EVM 컨트랙트 구조 분석

Chainlink CCIP EVM 컨트랙트 구조 분석

Ethereum Mainnet에서 Arbitrum으로 USDC를 보내거나, Polygon 컨트랙트가 Base 컨트랙트를 트리거하는 작업은 EVM 자체로는 불가능합니다. 체인은 기본적으로 서로 격리되어 있습니다. 크로스체인 브릿지가 이 공백을 메워 왔지만, 브릿지는 구조적으로 공격 표면이 넓어 업계 전반에서 보안 사고가 반복됐습니다.

더 보기
Circle CCTP V2 EVM 컨트랙트 파헤치기

Circle CCTP V2 EVM 컨트랙트 파헤치기

USDC를 한 체인에서 다른 체인으로 옮기는 브리지 설계는 크게 두 갈래로 나뉩니다. 하나는 lock-and-mint입니다. 원본 토큰을 소스 체인(source chain)의 컨트랙트에 잠가 두고, 목적지 체인(destination chain)에서 래핑 토큰을 찍어냅니다. 다른 하나는 burn-and-mint입니다. 소스 체인에서 토큰을 아예 소각하고, 목적지 체인에서 같은 양을 새로 발행합니다. Circle이 만든 CCTP(Cross-Chain Transfer Protocol)는 후자입니다.

더 보기
ERC-8004 에이전트 평판: 온체인 등록과 조회

ERC-8004 에이전트 평판: 온체인 등록과 조회

지난 글에서 ERC-8004/8126/8196 신뢰 스택 개요를 살펴봤다. ERC-8004는 AI 에이전트 신원 등록(Identity Registry), 평판 기록(Reputation Registry), 작업 검증(Validation Registry) 세 레지스트리를 정의하는 Ethereum Draft 표준이다. 개념 설명은 그 글에 정리돼 있으니, 여기서는 중복하지 않는다.

더 보기
2026년 AI x 블록체인 지형도: Bittensor, DePIN, 에이전트 금융

2026년 AI x 블록체인 지형도: Bittensor, DePIN, 에이전트 금융

AI와 블록체인을 결합한다는 말은 2020년대 초반에는 막연한 슬로건에 가까웠다. 2026년 현재, 그 결합이 네 개의 레이어로 구체화되고 있다. 분산 지능 레이어, 분산 GPU 컴퓨팅, 에이전트 금융, 머신 간 결제다. 각 레이어마다 살아남은 프로젝트와 사라진 프로젝트가 나뉘고 있다.

더 보기
AI 에이전트 신뢰 스택: ERC-8004, ERC-8126, ERC-8196

AI 에이전트 신뢰 스택: ERC-8004, ERC-8126, ERC-8196

AI 에이전트가 사용자를 대신해 자산을 쓰고, 컨트랙트를 호출하고, 유료 API에 접근하는 시대가 가까워지면서 “이 에이전트를 믿고 돈을 맡겨도 되는가"라는 질문이 실질적인 설계 문제가 됐다. 블록체인 커뮤니티는 이 문제를 세 계층으로 나눠 접근하고 있다. 신원 등록(ERC-8004), 보안 검증(ERC-8126), 정책 기반 실행(ERC-8196)이다.

더 보기
Figure: HELOC 대출에서 블록체인 자본시장 플랫폼으로

Figure: HELOC 대출에서 블록체인 자본시장 플랫폼으로

Figure라는 이름은 두 개의 회사를 가리킨다. 하나는 휴머노이드 로봇으로 알려진 Figure AI이고, 다른 하나는 이 글의 주제인 Figure Technology Solutions다. 두 회사는 무관하다.

더 보기
Lighter: Ethereum 위에서 동작하는 zk-SNARK 오더북 DEX

Lighter: Ethereum 위에서 동작하는 zk-SNARK 오더북 DEX

탈중앙화 거래소(DEX)는 크게 두 방식으로 나뉩니다. Uniswap처럼 유동성 풀 수식으로 가격을 결정하는 AMM(Automated Market Maker)과, 매도·매수 주문을 가격·시간 우선순위로 직접 대응시키는 오더북 방식입니다. AMM은 스마트 컨트랙트로 구현하기 쉽고 누구나 유동성을 공급할 수 있습니다. 반면 지정가 주문, 활발한 마켓 메이킹이 만드는 좁은 스프레드, 정밀한 가격 발견은 오더북 쪽의 영역입니다. Binance나 Coinbase 같은 중앙화 거래소(CEX)가 모두 오더북으로 동작하는 이유입니다.

더 보기
에이전트 결제 2026년 6월 동향: x402, UCP, MPP 구현 진전

에이전트 결제 2026년 6월 동향: x402, UCP, MPP 구현 진전

2026년 6월 에이전트 결제 관련 오픈소스 프로토콜들이 “에이전트가 결제할 수 있는가"에서 “누가 결제 권한을 갖고, 어떻게 검증하며, 어떻게 추적하는가"로 초점을 이동했다. x402, UCP, MPP/pay.sh, ACP 각각에서 크고 작은 구현 변화가 있었다. 이 글은 2026년 6월 한 달간 관찰된 주요 변화를 정리한다. 수치와 커밋 내용은 직접 확인한 GitHub API·PyPI·npm registry 기준이다.

더 보기
FHE·SP1·Groth16로 보는 비밀 투표 아키텍처

FHE·SP1·Groth16로 보는 비밀 투표 아키텍처

비밀 투표를 온체인에서 구현하면 즉시 세 가지 긴장이 생깁니다. 표 내용을 숨겨야 하는데 집계는 해야 하고, 오프체인 연산을 신뢰할 수 없는데 결과는 온체인에 확정해야 하며, EVM이 무거운 암호 연산을 직접 실행하기 어려운데 검증은 해야 합니다. FHE(완전 동형 암호), SP1 zkVM, Groth16 SNARK는 각각 이 세 가지 긴장을 담당합니다.

더 보기
카테고리
태그