실행 모델, 합의, EVM 기초, 검증 가능한 AI에 관한 기술 장문입니다. 각 통찰은 Web3를 더 선명하게 만듭니다.
편집자 추천단일 스레드 실행을 넘어서는 세 가지 성숙한 경로가 있습니다. Sealevel 방식의 결정론적 사전 선언, Block-STM 방식의 낙관적 동시성 제어, Sui 방식의 객체 모델입니다. 이 글은 각 접근의 전제와 개발자 비용, 그리고 EVM 호환성과의 관계를 비교합니다.
글 읽기 →
상태 변수는 선언 순서대로 32바이트 슬롯에 놓입니다. 작은 타입은 슬롯을 공유하고, 매핑과 동적 배열은 해시로 위치를 파생하며, 상속 순서는 슬롯 번호를 통째로 밀어냅니다. 이 배치 규칙이 업그레이드 프록시가 컴파일러가 할당하는 슬롯을 왜 비켜가야 하는지를 결정합니다.
네 가지 호출 명령어는 바이트코드에서 번호 몇 개만 다르지만, 그 의미는 코드가 누구의 컨텍스트에서 실행되고 누구의 스토리지에 쓰며 msg.sender와 address(this)가 무엇이 되는지를 결정합니다. CALL, CALLCODE, DELEGATECALL, STATICCALL을 하나씩 대조하면 프록시가 왜 DELEGATECALL에 의존하는지, STATICCALL이 무엇 때문에 도입되었는지가 분명해집니다.
가공되지 않은 calldata에서 출발해 ABI를 해부합니다. 4바이트 selector는 정규 시그니처를 잘라낸 것이고, 정적 타입은 한 워드를 그대로 차지하며, 동적 타입은 오프셋과 길이라는 2단계 주소 지정에 기댑니다. 이벤트는 indexed 매개변수를 topics에 기록해 검색 가능성을 얻습니다. ABI는 자기 서술적이지 않으므로 디코딩과 업그레이드 모두 제약을 받습니다.
이더리움 옐로 페이퍼는 블록 수준 상태 전이를 중첩 호출로 적었고, 그 결과 평가 순서는 명세의 일부가 됩니다. 트랜잭션을 하나씩 직렬로 처리하는 의미의 출처, 읽기/쓰기 집합 충돌을 미리 판정할 수 없는 이유, 결정성과 검증 단순성이 무엇을 얻어 냈는지, 그리고 이 설계 원점에 어떤 방식이 정면으로 응답하고 있는지가 이어지는 글의 주된 흐름입니다.
블록 헤더의 stateRoot는 32바이트에 불과하지만 네트워크 전체의 계정과 잔액, 컨트랙트 스토리지를 함께 묶어 둡니다. 아래에서는 Merkle Patricia Trie의 노드 구조와 계정 아래에 매달린 스토리지 트라이 설계를 뜯어보고, 머클 증명이 오프체인 검증을 어떻게 뒷받침하는지, 상태 팽창 비용이 누구에게 돌아가는지를 설명합니다.
Gas는 EVM의 자원 계량 단위이고 가격은 수수료 시장이 정합니다. 둘을 혼동하면 확장과 실행 중단의 경계를 잘못 판단하게 됩니다. 아래에서는 고유 비용과 동적 비용의 구성을 풀어내고, out-of-gas와 REVERT가 각각 무엇을 돌려주는지, EIP-1559의 base fee와 tip이 각각 누구에게 가는지 설명합니다.
같은 32바이트 데이터를 memory, storage, transient storage 중 어디에 두느냐에 따라 가스 비용이 두 자릿수 배 차이 나고 수명도 완전히 달라집니다. 아래에서는 소유, 수명, 과금이라는 세 축으로 세 가지 스토리지를 나누어 설명하고, 재진입 잠금과 임시 배열, 상태 변수를 각각 어디에 두어야 하는지 정리합니다.
EVM은 레지스터가 없는 스택 기계입니다: 256비트 워드 크기, 1024개 스택 깊이, JUMPDEST로만 점프할 수 있는 프로그램 카운터를 갖습니다. 인출, 해독, 실행이라는 이 루프는 스택 언더플로와 오버플로가 왜 gas를 전부 태우는지, 그리고 스택 기계가 레지스터 기계에 비해 무엇을 얻고 무엇을 치렀는지 설명합니다.
이더리움을 이체를 기록하는 원장으로 보면 가장 중요한 부분, 즉 계정 스토리지에 임의로 읽고 쓸 수 있는 변수를 놓치게 됩니다. 옐로 페이퍼의 상태 전이 함수 Υ(σ, T)에 따르면 이더리움은 분산 상태 기계이고, EVM은 이 상태 전이의 실행 명세입니다. 전 네트워크가 비트 단위로 재실행한다는 사실은 실행 의미론에 일련의 강한 제약을 부과합니다.
병렬 EVM은 이체 벤치마크에서는 좀처럼 무너지지 않지만, AMM과 대출, NFT 민팅 트래픽에서는 자주 주저앉습니다. 이 글은 충돌 핫스팟이 어떻게 형성되고, 읽기/쓰기 집합의 입자성이 충돌률을 어떻게 좌우하며, 실제 워크로드에서 최대 TPS가 어떻게 저하되는지 설명합니다.
더 높은 TPS를 더 비싼 하드웨어와 더 적은 검증인으로 사는 것일까요? 이 글은 검증인 요건과 지리, 클라이언트 다양성이라는 검증 가능한 차원을 풀어내고 BLS 집계 같은 엔지니어링 대응을 과장 없이 논의합니다. 투자 조언이 아닙니다.
TPS, BPS, 확인 지연, 최종성, 충돌률은 흔히 뒤섞입니다. 이 글은 재사용 가능한 정의, 흔한 오용 패턴, 그리고 어떤 벤치마크든 요구해야 할 공개 체크리스트를 제공합니다 — 투자 조언이 아닙니다.
컨트랙트 개발자, 클라이언트 엔지니어, 연구자는 서로 다른 이유로 병렬 EVM에 관심을 가집니다. 이 글은 이 사이트에 이미 발행된 글만 가리키는 세 가지 읽기 경로를 제시하여 각 독자가 무엇을 읽고 무엇을 건너뛸지 찾을 수 있게 합니다.
"EVM 호환"은 흔히 한 줄짜리 마케팅 문구로 납작해집니다. 실제로 마이그레이션 비용을 결정하는 것은 바이트코드 의미론, 프리컴파일 집합, JSON-RPC 동작, 그리고 Foundry/Hardhat이 그대로 작동하는지 여부입니다. 이 글은 그 네 계층을 분리하고 병렬화가 호환성을 왜 더 어렵게 만드는지 설명합니다.
낙관적 병렬 EVM L1을 선택한다는 것은 정산 도메인, 호환성, 병렬화 전략에서 동시에 트레이드오프를 감수한다는 뜻입니다. 이 글은 Bitroot가 해결하는 것과 해결하지 않는 것, 즉 구호가 아닌 경계를 밝히고 각 기술 요소가 어떻게 서로를 받치는지 설명합니다.
낙관적 동시성 제어는 1981년 데이터베이스 연구에서 시작되어 오늘날 많은 병렬 EVM을 떠받칩니다. 이 입문 글은 읽기–검증–쓰기 단계를 설명하고, OCC를 비관적 잠금 및 MVCC와 대비하며, 블록체인이 추가하는 결정성과 비잔틴 제약을 정리합니다.
단일 스레드 실행을 넘어서는 세 가지 성숙한 경로가 있습니다. Sealevel 방식의 결정론적 사전 선언, Block-STM 방식의 낙관적 동시성 제어, Sui 방식의 객체 모델입니다. 이 글은 각 접근의 전제와 개발자 비용, 그리고 EVM 호환성과의 관계를 비교합니다.
"확장"은 흔히 하나의 문제로 취급됩니다. 이 글은 그것을 합의, 데이터 가용성, 실행, 정산으로 나누고 L2, 샤딩, 독립형 DA, L1 병렬 실행을 그 지도 위에 놓으며, 병렬 EVM이 어디에 위치하는지도 밝힙니다.
이더리움의 주요 혼잡 사건은 하나의 설계 뿌리를 공유합니다. EVM이 트랜잭션을 한 번에 하나씩 실행한다는 점입니다. 이 글은 가스 한도 상향과 EIP-1559가 그 실행 모델을 바꾸지 못하는 이유, 그리고 확인 지연이 단일 스레드 한계를 증폭하는 방식을 설명합니다.
AI에서 데이터·모델·컴퓨팅 기여자가 자동 정산을 받지 못하는 이유, 그리고 온체인 메타데이터 인덱스, 임계값 샤딩, TEE 보조 감사, 스마트 컨트랙트 분배가 각각 무엇을 해결하고 무엇을 해결하지 못하는지—더불어 권리가 정산과 신뢰 컴퓨팅 위에 어떻게 놓이는지를 설명합니다.
