블록체인 합의 설계와 스마트 컨트랙트 Gas 최적화

합의와 실행 비용이 만나는 지점

블록체인은 합의 알고리즘과 가상머신 실행 모델 위에서 분산 애플리케이션을 구동한다. 합의 방식의 트레이드오프, 스마트 컨트랙트 구현, Gas 비용 분석은 분리된 과제가 아니다. 하나의 설계 결정이 최종성, 수수료, 처리 지연, 운영 부담으로 이어진다.

합의 알고리즘은 분산 환경에서 동일한 상태에 도달하기 위한 프로토콜 집합이다. 설계의 중심에는 안전성(일관성)과 활성(진행성)의 균형이 있다. Nakamoto PoW, PoS(캐스퍼/이더리움), BFT류(Tendermint/HotStuff), PoA가 대표적이다.

스마트 컨트랙트 최적화는 EVM/ewasm 등의 실행 환경에서 상태 접근, 메모리·스토리지 사용, 연산 비용을 줄이는 코드와 데이터 구조 설계다. 이때 가독성과 보안을 희생하지 않으면서 Gas 비용의 균형점을 찾아야 한다.

Gas 분석은 BaseFee/Tip, 오퍼코드(OPCODE) 비용, 스토리지 I/O, L2 데이터 가스(DA)처럼 트랜잭션 실행 비용을 구성하는 요소를 계측하고 해석하는 작업이다. 네트워크 수수료 시장(EIP-1559), Gas 스케줄(EIP-2929/3529 등), L2 특성을 함께 반영해야 하며 최신 정보 확인이 필요하다.

합의 모델이 바꾸는 최종성과 운영 방식

합의 계층에서는 최종성 모델부터 확인해야 한다. Nakamoto 계열은 확률적 최종성에 의존하므로 확인 블록 수가 중요하다. BFT와 PoS 계열은 즉시 또는 경제적 최종성을 제공하며, 체크포인트와 슬래싱 같은 파라미터가 설계에 들어간다.

블록 간격, 블록 가스 한도, 검증자 수, 네트워크 동기화 가정은 TPS와 지연에 직접 영향을 준다. 운영 관점에서는 키 관리, 위임·스테이킹, 노드 업그레이드, 하드포크 관리, 모니터링 체계도 함께 감당해야 한다.

합의	성능(지연/TPS)	확장성	일관성/최종성	안정성(공격·분기)	운영 편의
PoW (Nakamoto)	중간/낮음	높음(퍼블릭)	확률적 최종성, 확인 블록 필요	높은 검증 비용, 51% 공격 가능성	낮음(전력·하드웨어 부담)
PoS (이더리움)	중간/중간	높음(검증자 확장)	경제적 최종성(체크포인트)	슬래싱 기반 억지, 장기 검열 리스크	중간(스테이킹·키 관리)
BFT (Tendermint/HotStuff)	낮은 지연/높은 TPS(수십~수천)	중간(수백 검증자 한계)	즉시 최종성	비잔틴 내성 f < n/3	높음(엔터프라이즈 적합)
PoA	낮은 지연/높은 TPS	중간	즉시/관리형 최종성	소수 권한자 신뢰 의존	높음(사설망 간편)

비교 기준은 지연, TPS, 최종성, 공격 내성, 운영 복잡도다.

EVM 비용 모델에서 확인할 항목

EIP-1559 환경에서는 BaseFee가 자동 조정되고 Priority Fee(팁)가 별도로 지불된다. 따라서 MaxFee와 MaxPriorityFee를 어떻게 설정할지 결정해야 한다.

실행 비용은 SLOAD/SSTORE, LOG, CALL 계열의 비용 비대칭성과 cold/warm access 차등 비용의 영향을 받는다. 롤업에서는 실행 가스와 L1 데이터 가스(증명/블롭)를 분리해 봐야 한다. EIP-4844(Blob Gas) 도입 영향도 존재하며 최신 정보 확인이 필요하다.

코드 수준에서는 다음 영역이 주요 최적화 대상이다.

변수 패킹, SLOAD 캐싱, 상태 쓰기 횟수 최소화로 스토리지 사용을 줄인다.
calldata를 활용하고 불필요한 메모리 확장을 피하며, revert 사유 대신 Custom Error를 사용한다.
unchecked 증가, 단일 패스 집계, 필요한 필드만의 이벤트 인덱싱으로 제어 흐름을 다듬는다.

과도한 inline assembly는 가독성을 떨어뜨리고 취약점 위험을 높일 수 있다. 코드 리뷰와 형식 검증을 함께 적용해야 한다. 합의 파라미터도 성능을 높이는 방향으로만 조정하면 중앙화와 검열 위험이 커질 수 있으므로, 슬래싱과 인센티브 설계를 병행한다.

트랜잭션 처리와 Gas 소비 흐름

⤢✕

서명·nonce 불일치, GasLimit/Out-of-Gas, require/assert 실패는 롤백으로 처리된다. 트랜잭션은 합의 적용, 상태머신 전이, 최종성 도달의 순서로 일관성을 확보한다.

구현 방식에 따른 Gas 절감 사례

L2 DEX 스왑에서는 다중 풀 조회에 필요한 값을 calldata 파라미터로 전달해 on-chain 탐색을 제거할 수 있다. fee, reserves 같은 값을 저장소에서 캐싱하면 SLOAD도 줄어든다. 스왑 실행당 20~~35% Gas를 절감하고, L1 데이터 가스 부담이 동일한 경우 총 수수료를 15~~25% 절감할 수 있다.

NFT 대량 민팅에는 비순차 ID 할당 대신 연속 ID와 비트맵 소유권 기록을 사용할 수 있다. Merkle-tree 화이트리스트 검증도 calldata 증명 방식으로 이전한다. 민팅당 30~60% Gas 절감과 실패 트랜잭션 재시도 비용 감소가 기대된다.

DAO 거버넌스는 오프체인 서명을 수집하고 온체인 검증을 최소화하는 방식으로 가볍게 구성할 수 있다. Checkpointed ERC20을 사용하면 제안당 Gas를 40%+ 절감하고, 체인 혼잡 시 팁 경쟁 비용을 낮출 수 있다.

엔터프라이즈 프라이빗 체인에서는 BFT(HotStuff/Tendermint)를 선택해 즉시 최종성과 감사 추적성을 확보한다. 초저지연 결재 처리와 운영 규제 준수에 유리하다.

상태 접근을 줄이는 컨트랙트 구현

전제조건은 Solidity 0.8.24+, Foundry 1.0+ 또는 Hardhat 2.20+, EVM: Ethereum/L2 호환이다.

동일 슬롯을 여러 번 읽는 변수는 로컬 변수로 캐싱한 뒤 일괄 쓰기하고, bool이 여러 개인 경우 uint256 비트 패킹을 적용할 수 있다. external 함수 파라미터에는 memory 대신 calldata를 사용하고, revert 문자열 대신 Custom Error를 검토한다. 루프 인덱스의 unchecked 증가와 내부 조건식 단순화도 대상이며 이벤트에는 필요한 필드만 indexed로 둔다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

// Before: 불필요한 SLOAD, memory 사용, revert 문자열
contract VaultBefore {
    mapping(address => uint256) public balance;

    function deposit() external payable {
        balance[msg.sender] = balance[msg.sender] + msg.value; // SLOAD + SSTORE
    }

    function withdraw(uint256 amount) external {
        require(balance[msg.sender] >= amount, "INSUFFICIENT");
        balance[msg.sender] -= amount; // SLOAD + SSTORE
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "SEND_FAIL");
    }
}

// After: SLOAD 캐싱, Custom Error, Checks-Effects-Interactions
error Insufficient();
error SendFail();

contract VaultAfter {
    mapping(address => uint256) public balance;

    function deposit() external payable {
        uint256 b = balance[msg.sender];
        unchecked { b += msg.value; }
        balance[msg.sender] = b; // 1 x SLOAD + 1 x SSTORE
    }

    function withdraw(uint256 amount) external {
        uint256 b = balance[msg.sender]; // 1 x SLOAD
        if (b < amount) revert Insufficient();
        unchecked { balance[msg.sender] = b - amount; } // 1 x SSTORE
        (bool ok, ) = msg.sender.call{value: amount}("");
        if (!ok) revert SendFail();
    }
}

배열 순회가 잦다면 매핑과 보조 인덱스 구조를 고려한다. immutable/constant는 스토리지 접근을 없애며, 라이브러리 재사용은 코드 중복과 바이트코드 크기 관리에 도움이 된다.

inline assembly는 EVM 스택 안전성 검사가 누락될 위험이 있으므로 회귀 테스트와 형식 검증을 사용한다. Checks-Effects-Interactions와 재진입 보호(ReentrancyGuard)는 유지해야 한다.

계측부터 회귀 방지까지 이어지는 Gas 분석

먼저 평균·최악 케이스를 포함하는 대표 시나리오 벤치마크를 정하고 forge snapshot 또는 수동 시뮬레이션으로 기준선을 만든다. 이후 forge test --gas-report 또는 hardhat-gas-reporter로 함수별 Gas를 측정하고, geth/erigon debug_traceTransaction으로 opcode 수준의 핫스팟을 확인한다.

개선은 단일 변경점씩 적용한 뒤 다시 측정한다. 효과가 5~10% 미만이면 되돌리고, Foundry fuzz와 Echidna를 이용한 Differential fuzzing으로 논리 등가성을 확인한다. CI에서는 gas snapshot을 비교하고, 예를 들어 3% 초과 증가 시 실패하게 설정한다. 릴리스 노트에도 Gas 영향을 남긴다.

// package.json: hardhat-gas-reporter 설치 필요
// npm i -D hardhat hardhat-gas-reporter
require("hardhat-gas-reporter");

module.exports = {
  solidity: "0.8.24",
  gasReporter: {
    enabled: true,
    currency: "USD",
    coinmarketcap: process.env.CMC_KEY,
    excludeContracts: ["mocks/"],
    showMethodSig: true,
  },
};

# foundry.toml
[profile.default]
src = "src"
out = "out"
evm_version = "paris"
gas_reports = ["*"]

forge test --gas-report

온체인에서는 Etherscan/Blockscout trace와 Tenderly 시뮬레이션으로 실제 네트워크 혼잡과 BaseFee 영향을 포함해 검토한다. L2는 실행 가스와 데이터 가스(증명/블롭)를 분리해 분석해야 하며, 롤업별 과금 모델 차이가 존재한다. 최신 정보 확인이 필요하다.

파라미터 조정과 업그레이드 운영

블록 가스 타깃, 슬롯/에폭 길이, 검증자 집합 크기는 목표 TPS에 맞춰 조정하되 지연과 중앙화 리스크를 함께 고려한다. 슬래싱 조건과 지연 벌점을 명확히 하고, MEV 완화를 위해 프라이버시 멤풀/프리컨피그를 도입할 수 있다.

하드포크나 프로토콜 변경에는 다중 클라이언트 테스트넷 검증과 데이터 마이그레이션 계획이 필요하다. 컨트랙트 최적화, 합의 파라미터, 업그레이드 절차를 따로 다루면 성능 개선이 안정성 저하로 이어질 수 있다.

컨트랙트 최적화로 함수별 Gas를 20~~60% 절감하고, 트래픽 의존적으로 월간 수수료를 25~~45% 절감할 수 있다. 합의 파라미터 조정은 지연을 30~~70% 개선하고 안정적 TPS를 1.5~~3배 향상할 수 있다. 회귀 테스트와 스냅샷 기반 CI는 Gas 급증 사고를 줄이고 릴리스 실패율을 20% 이상 낮출 수 있으며, 즉시 최종성 합의 도입은 결제 실패·재조정 비용 감소로 이어진다.