티스토리 뷰
EIP-1559는 2019년 4월에 처음 제안된 이후 가장 주목 받았으며 업그레이드가 기다려졌던 개선안 중 하나이다. EIP-1559는 실제로 런던 하드포크 이후 이더리움의 거래 모델에 큰 변화를 가져오기도 했다. EIP-1559가 무엇인지 이더리움 네트워크에 어떤 영향을 끼쳤는지 알아보자.
+ 참고 사항
현재 이더리움은 2022년 9월 중순에 있었던 머지 후 PoW 에서 PoS 로 전환되었다. 이 글을 쓰던 시점은 머지 전 PoW 체재였기에 아래 내용에서 채굴 및 채굴자에 관한 이야기가 나온다. 이더리움이 PoS로 전환되었음에도 EIP-1559 수수료 체계는 계속 유지 중이므로 아래의 내용이 현재 상황에 그대로 적용된다. 다만, 현재는 블록 보상이 채굴자가 아닌 검증자에게로 간다는 점만 인지하고 이 글을 읽어주길 바란다.
런던 하드포크
이더리움은 2021년 8월4일(한국 시간 기준, 8월 5일)에 아주 중요한 업데이트를 하게된다. 이더리움의 고질적인 문제점을 개선하기 위해 런던 하드포크를 진행한 것이다( 런던에서 열렸던 개발자 회의에서 업데이트 내용이 확정되어 런던 하드포크라고 불림 ). 기존 이더리움 네트워크는사용자들이 수수료 값을 어림짐작으로 예측하여 지불했으며 트랜잭션 처리 속도가 느렸다. 이 부분을 해결하고자 런던 하드포크에서 총 5가지의 이더리움 개선 제안(EIP)을 채택하여 업그레이드를 진행하게 된다. 5가지 사항은 아래를 참고하길 바라며 그 중 가장 중요한 사항은 수수료 정책 개선에 관한 부분으로 EIP-1559 이다.
- EIP-1559 : Fee market change for ETH 1.0 chain
- EIP-3198 : BASEFEE opcode
- EIP-3529 : Reduction in refunds
- EIP-3541 : Reject new contract code starting with the 0xEF byte
- EIP-3554 : Difficulty Bomb Delay to December 2021
Legacy 수수료 정책( Before )
이더리움의 수수료 정책이 어떻게 변화되었는지 알기 위해선 기존의 레거시 수수료 모델을 이해할 필요가 있다. EIP-1559 업그레이드 전, 이더리움 사용자들은 거래를 하기 위해 네트워크 혼잡도에 따라 수수료를 어림짐작으로 예측하여 제출했다. 이때는 블록 채굴자들이 블록 채굴 보상으로 블록에 포함되는 모든 거래들의 수수료를 가져가는 구조였기에 블록 채굴자들은 수수료가 높은 거래를 위주로 거래들을 골라 담아 갔다. 사용자들은 자신의 거래가 빨리 수행되기 위해선 더 높은 수수료를 내고 블록에 채택되길 기다려야했다.
여기서 가장 큰 문제점은 사용자들은 어느 정도의 수수료를 지불해야 블록에 포함되는지 모르는 점이다. 그래서 사용자들은 거래가 빨리 수행되길 바라며 수수료 경매장에 입찰을 해나갔고 수수료 경쟁을 스스로 심화 시켰다.
이러한 문제점은 가스비를 예측하기가 힘들어 매번 수수료 변동 폭이 커지면서 블록체인 프로젝트나 DApp을 운영하는데 어려움이 발생하고 사용자들의 불편함을 초래했다.
문제점은 하나 더 존재했다. 바로 블록의 크기이다.
EIP-1559 업그레이드 전, 모든 블록은 동일한 블록 크기(Block Limit)를 가졌다. 거래가 몰리는 혼잡한 시간대나 널널한 시간대 전부 상관없이 블록은 크기가 정해져 있었기에 처리하는 트랜잭션 수량이 항상 일정했다. 그렇기에 거래가 몰리는 시간이면 블록을 생성하는 시간보다 처리해야할 거래 수가 많고, 거래를 담아가는 수량도 일정하기에 거래 확정 시간이 늦어질 수 밖에 없었다. 거래 확정이 늦어지면 사용자들은 수수료를 더 높여서 지불했고 이 또한 수수료가 상승하는 주된 원인이 되었다.
아래 사진을 보면서 예를 들어보자. 본인은 수수료 20 Gwei에 거래를 제출했다. 제출하기 전에는 최근 블록의 수수료 평균 가격이 20 Gwei 였기 때문이다. 하지만 제출한 시점에 갑자기 네트워크가 혼잡(가스 스파이크)해져서 블록의 평균 수수료가 100 Gwei까지 상승하였다. 블록은 담아갈 수 있는 거래 수가 정해져있어서 100 Gwei 이상의 거래만 골라서 담게된다. 본인의 거래는 2번째, 3번째 블록에서 계속 보류 중( pending )이며 수수료 평균이 20 Gwei로 낮아질때까지 기다렸다가 4번째 블록이 생성되어서야 거래가 확정된다.
기존 레거시 정책은 그야말로 수수료 경쟁을 심화할 수 밖에 없는 구조인 것이다. 개발자들은 이러한 문제점들을 개선할 필요성을 느꼈고 런던 하드포크를 진행하게 된다.
EIP-1559 수수료 정책
EIP-1559의 목적과 개선 사항은 아래와 같다.
1. 사용하게 될 수수료 예측을 더 쉽게할 수 있도록 하자
2. 블록 크기가 가변적으로 변하게 해서 수요가 급증할때 크기를 2배로 증가시켜 트랜잭션(거래) 확정 시간을 줄이자
3. 네트워크 현재 수요에 따라 알고리즘으로 가스비가 자동 결정되게 함으로써 UX를 개선하자
4. 사용자가 지불한 요금 중 일부가 연소(Burn)되어 이더의 희소성을 높이자. 거래 이용 증가가 곧 모든 이더 홀더들에게 이익으로 돌아갈 것이다
아래부터는 EIP-1559로 업그레이드 되고나서 새로 등장한 개념들을 설명한다.
가변 블록 크기(Variable Block Size)
기존에 이더리움의 블록은 하나의 블록에 들어갈 수 있는 블록의 크기(Block Limit)가 1500만 가스로 제한을 두고 있었다. 네트워크가 혼잡할 때마다 블록은 꽉 차 있었고 거래를 빨리 확정하기 위해서 가스 가격이 급격하게 상승하였다.
EIP-1559는 이 문제점을 개선하기 위해 혼잡도에 따라 블록 크기를 일시적으로 늘릴 수 있도록 업데이트 했다. 현재 블록은 기존보다 2배의 크기로 최대 3000만까지 제한을 늘릴 수 있다.
EIP-1559 이후 새로운 개념이 등장하는데 바로 Limit와 target이다. EIP-1559 이후에 [50% 만큼 가득차 있는] 블록의 Limit는 EIP-1559 이전에는 원래 [100% 만큼 가득차 있는] 블록의 Limit과 같다고 볼 수 있다. 따라서 현재 시점으로 블록이 1500만 가스를 사용했으면 gas Target이 +50% 만큼 사용했다고 말할 수 있고, 블록이 3000만 가스를 사용했으면 gas Target이 +100% 만큼 사용했다고 말할 수 있다.
이더리움은 각 블록들이 50%만큼 가스를 사용하는 것이 가장 이상적이며 가장 적합한 목표치라 말한다. 블록 크기를 늘리는 것도 공짜는 아니기 때문이다. 목표치 이상을 사용하게 되면 수수료 기본 평균이 인상되고, 작게 사용하게 되면 반대로 감소한다. 급격한 수수료 변동 폭을 줄이기 위해 수수료 기본 가격의 상승과 감소의 폭은 12.5%로 제한했다.
아래 사진으로 예를 들어보자. 본인은 수수료 20 Gwei에 거래를 제출했다. 현재 블록의 기본 수수료가 20 Gwei였기 때문이다. 이때, 제출한 시점에 갑자기 네트워크가 혼잡(가스 스파이크)해졌다. 하지만 갑자기 기본 수수료가 증가하지는 않는다. 대신 몰리는 거래량을 수용하기 위해 블록의 크기가 커진다. 2번째 블록이 커졌기에 커지는 만큼 다음 3번째 블록의 기본 수수료가 증가하여 22.5 Gwei가 되었다. 3번째 블록에서도 거래가 몰려 블록 크기가 커졌기에 4번째 블록 또한 기본 수수료가 25 Gwei로 높아진다. 하지만 혼잡도가 높진 않아 블록 크기가 줄어들었다. 이때 본인은 20 Gwei의 수수료를 제출했기에 2번째 블록에서 거래가 확정되었다.
요약하자면 EIP-1559를 적용한 뒤에 블록 크기가 가변적으로 변동할 수 있어 네트워크 혼잡도에 따라 대응할 수 있고, 수수료 가격 변동성이 적기 때문에 기존 레거시 정책보다 거래가 더 빨리 확정된다.
BaseFee
블록에 트랜잭션을 포함하기 위해 필요한 최소 가스 가격이다(가스 단위당 Gwei). 블록에 포함되는 트랜잭션(거래)들은 모두 기본적으로 BaseFee를 기반으로 gasPrice(가스 가격)이 측정된다. BaseFee(기본료)는 이더리움 네트워크의 혼잡도에 따라 프로토콜에 의해 알고리즘적으로 설정된다.
블록에서 가스의 50% 이상 사용되면 BaseFee는 증가하고, 50% 미만으로 사용이 감소하면 기본료도 감소된다. 사용이 증가하고 감소하고는 부모 블록의 parentGasUsed와, parentGasTarget 값을 참고하여 결정된다. gasTarget이란 부모 블록보다 gas를 얼마나 더 소비했는지(gasUsed)를 나타내는 측정 값이다. 즉, parentGasTarget이 50%보다 크기가 높으면 블록의 BaseFee가 증가하고, parentGasTarget 값이 50%보다 크기가 낮으면 블록의 BaseFee가 감소한다.
블록의 BaseFee는 부모 블록에 비해 블록이 가득찼는지를 기준으로 ±12.5%까지 크기가 변동될 수 있다. 즉 BaseFee(기본료)가 부모의 BaseFee를 기준으로 ±12.5까지 변동이 가능하다고 예측이 가능한 것이다.
PriorityFee
사용자가 거래를 블록에 포함시기위해 채굴자에게 직접 지불하는 가스 가격(가스 단위당 Gwei)으로 급행료 또는 팁(Tip)이라고 부르기도 한다.
채굴자의 채굴 보상이 트랜잭션의 모든 gasPrice를 받는 것에서 트랜잭션의 모든 PriorityFee를 받는 것으로 변경되었다. PriorityFee는 사용자가 직접 설정하며 PriorityFee를 많이 내는 사람일수록 더 빨리 블록에 포함된다.
레거시때의 수수료 경쟁과 다른게 뭔지 궁금할거라 생각한다. 팁은 보통 1~3 Gwei 밖에 되지 않으며 이더리움 연구소에서 추천하는 가격은 2 Gwei라고 한다. 2 Gwei는 절대 적은 금액이 아니며 블록에 빠르게 포함가능한 수치이다. 팁 또한 변동 폭이 적으니 레거시때보다 수수료 경쟁이 완화되었고 사용자 편의 환경이 훨씬 상향되었다고 말할 수 있겠다.
MaxFee
사용자가 트랜잭션에 대해 지불할 의사가 있는 최대 가스 가격(가스 단위당 Gwei)으로 트랜잭션을 제출할때 사용자가 직접 설정한다. MaxFee는 BaseFee보다 낮게 설정할 수 없다.
수수료 계산 방법
트랜잭션을 처리할때 사용자는 BaseFee와 PriorityFee를 수수료로 주게되는데, 채굴자들이 수수료를 높이는 조작 행위를 방지하기 위해 BaseFee는 소각된다. 또한 제출하는 수수료의 최대 금액을 사용자가 직접 설정하여 수수료 지불의 제한선을 두었다.
사용자는 잔고를 확인 한 뒤 최대로 지불할 수 있는 두 개 값을 설정한다. 이때 두 값의 최대값을 maxFeePerGas와 maxPriorityFeePerGas라고 한다.
maxFeePerGas
maxFeePerGas는 자신이 최대로 허용할 수 있는 가스의 최대 가격이다.
본인이 현재 트랜잭션을 제출한다고 가정해보자. 본인은 현재 이미 생성된 부모 블록의 BaseFee 값은 알 수 있지만, 본인이 제출할 트랜잭션이 어떤 블록에 담길지는 알 수 없기에, 담길 블록의 BaseFee를 알 수 없는 상태이다. BaseFee를 알 수 없으니 최대로 지불할 수있는 MaxFee 값을 정할 것이다. 본인은 Max값을 200 Gwei로 제출했다. 막상 거래가 확정되고 확인한 BaseFee는 100 Gwei 였다. 본인은 수수료를 100 Gwei 더 높게 설정했지만 이것은 채굴자에게 모두 지불 되지않고 초과된 100 Gwei는 다시 환불된다.
이때 중요한 점은 MaxFee를 BaseFee보다 낮게 설정하면 거래가 처리되지 않거나 계속 pending 상태로 머물러있다. 그렇다면 MaxFee는 얼마를 측정해야 좋을까? 아래의 공식으로 MaxFee를 구할 수 있다.
MaxFee = ( BaseFee * 2 ) + maxPriorityFee
BaseFee의 2배를 곱하는 이유는 이렇게하면 통상적으로 gasTarget이 100%인 블록의 6개는 무난하게 통과된다고 한다.
maxPriorityFeePerGas
maxPriorityFeePerGas는 채굴자에게 줄 수 있는 팁의 최대값이다. maxPriorityFeePerGas을 0으로 설정하면 채굴자에게 주어지는 이더가 없기 때문에 채굴자가 트랜잭션을 후순위로 처리할 가능성이 높다.
본인이 현재 트랜잭션을 제출한다고 가정해보자. BaseFee가 100 Gwei 인데 maxFeePerGas를 300 Gwei로 주고, maxPriorityFeePerGas를 5 Gwei로 입력하여 트랜잭션을 제출하였다. 100 Gwei(BaseFee) + 5 Gwei(maxPriorityFeePerGas) = 105 Gwei를 최종 지불하게 된다. 이때 채굴자는 오직 팁만 보상으로 가질 수 있기에 실제로 채굴자에게 지급되는 금액은 5 Gwei 이다. 100 Gwei는 소각되고, 초과 지출한 200 Gwei는 환불된다.
실제로 채굴자에게 지급되는 금액은 maxPriorityFeePerGas 값과 maxFeePerGas에서 BaseFee를 뺀 값 두개 중에 가장 최소값이 지불된다.
Legacy와의 비교
EIP-1559 이전(Legacy)의 수수료를 구하는 법은 아래와 같다.
Transaction Fee = gasPrice * gasLimit
EIP-1559 이후는 gasPrice가 사라지고 BaseFee와 PriorityFee를 더한 금액에서 사용한 가스만큼을 곱한 금액이 최종 지불하는 수수료이다.
Transaction Fee = ( BaseFee + PriorityFee ) * gasUsed
BaseFee는 프로토콜에서 자동적으로 산출되기에 레거시 때보다 수수료 급등 현상을 막을 수 있고, 수수료가 어느 정도인지 예측할 수 있게 되어 사용자에게 편의를 제공한다.
이더리움 소각
EIP-1559가 주목과 지지를 받게된 주된 이유는 사용자가 지불한 수수료 중 일부가 소각되어 채굴자에게만 집중되어 있던 보상을 이더리움 네트워크 사용자 전체에게 돌아가도록 한다는 기능이 있어서이다. 사용자는 BaseFee와 PriorityFee를 수수료로 지불하며 채굴자에게는 보상으로 PriorityFee만 주어지고 BaseFee는 모두 소각된다. 사용자들의 거래량이 많아질수록 비례하여 이더가 소각되므로 이더의 희소성이 증가하여 가격이 상승하는 것이다. 이더리움 네트워크의 모든 사용자들에게 균등하게 보상이 주어지는 것이다.
이더 소각은 네트워크 전체에 긍정적인 영향을 끼치기도 하지만 비판도 존재한다. 긍정적인 영향은 네트워크 사용률이 충분히 높을때에만 이익을 얻을 수 있는 것이며, 소각이 계속 지속되면 이더 발행량보다 소각량이 초과할 수 있어 이더의 인플레이션을 일으킬 것이다라는 허를 찌르는 비판도 받아왔다.
하지만 이더리움 2.0의 도입을 위해서는 결국 이더 발행 수량을 줄이는 것이 맞는 방향이다. 이후 곧 난이도 폭탄이 도래하여 채굴자들이 줄어들 것이고 자연스레 이더 발행 또한 줄어들 것이다. 이더 소각에 대해 불평하는 사람은 드물 것이다.
마무리
EIP-1559의 이점을 요약하자면 아래와 같다.
거래 수수료 정책 개선 : 프로토콜 알고리즘에 따라 수수료가 책정되므로 사용자는 변화하는 가스 가격을 예측할 필요가 없다.
초과 수수료 지급 감소 : 사용자는 자신이 지불한다고 제출한 금액에 관계없이 계산된 최소의 금액(BaseFee + PriorityFee)만 지불한다.
신뢰성 높은 트랜잭션 처리 방식 : 네트워크의 혼잡으로 인해 가스 가격이 급등하는 현상을 블록의 크기를 먼저 변경함으로써 제한한다.
이더 보유자와 이더리움 네트워크에 긍정적인 관계를 유지 : 이더 보유자는 BaseFee 소각에 의해 이더리움 네트워크 상에서 이익을 얻는다.
EIP-1559가 업데이트 되면서 메타마스크 등 DApp 및 지갑 서비스들도 업데이트를 진행했다. 수수료의 양을 높게~낮게 설정함으로써 사용자에게 편리한 UX를 제공할 수 있게된 것이다. 확실히 이전보다 이더리움 거래를 하는 것에 쉽게 접근하도록 편의를 높였다고 생각한다.
EIP-1559의 장점은 명확하지만 아직은 체감적으로 수수료가 낮아졌다고 느끼긴 힘들다. NFT의 수요가 급등하며 전체적으로 수수료 값이 상승하여 본인은 이전과 크게 달라진 점은 느끼지 못하겠다. 수수료가 쎄다는 진입장벽이 아직 존재하기에 이더리움의 업데이트는 계속해서 개선해 나가야한다고 생각하며 이더리움 2.0이 하루빨리 도입되어 변화를 지켜봐야할 것이다.
Reference
'BlockChain > Ethereum' 카테고리의 다른 글
[Ethereum] Goerli 테스트넷 Faucet 이더 얻기 (1) | 2022.08.11 |
---|---|
[Ethereum] hardhat으로 contract 작성 & 테스트넷 배포하기 (0) | 2022.08.11 |
[Ethereum] hardhat 설치 및 환경설정 (0) | 2022.08.10 |
[Ethereum] 이더스캔(Etherscan) 보는 방법, 개발 용어 정리 (2) (0) | 2022.06.14 |
[Ethereum] 이더스캔(Etherscan) 보는 방법, 개발 용어 정리 (1) (0) | 2022.06.10 |