EIP-1559

EIP-1559

2020, Dec 27    

이더리움에서는 트랜잭션을 처리할 때 가상의 연료인 “가스(gas)”를 사용합니다. 사용자는 가스에 대한 가격을 정해서 트랜잭션을 처리해주는 채굴자에게 지불합니다. 이러한 수수료 체계에 대한 개선안이 EIP-1559 입니다.

Gas, Gas price

트랜잭션을 처리하기 위해 실행되는 코드는 정해진 가스 값을 소모하도록 되어 있습니다. 수수료는 그렇게 소모되는 가스에 대해 사용자가 얼마의 이더를 지불할 것인가에 따라 결정됩니다. 이더리움에는 수수료 시장 “fee market”이라는 것이 있습니다. “fee”는 사전적인 의미 그대로 이더리움 네트워크에서 트랜잭션을 처리할 때 드는 비용, 수수료를 말합니다. 이 수수료는 채굴자들이 가지게 됩니다.

그렇다면 “market”은 어떤 의미일까요? 트랜잭션 처리가 필요한 수요자와 트랜잭션 처리를 해주는 공급자로 이루어지는 “시장”을 의미합니다. 블록체인의 탈중앙화라는 특성때문에, 즉 어느 특정 주체가 트랜잭션을 처리해주지 않기 때문에 수요자가 제시하는 수수료와 그 수수료를 받고 트랜잭션을 처리해주는 공급자가 서로의 이해관계에 따라 만나는 “시장”이 형성될 수 있는 것입니다. 수요곡선과 공급곡선이 만나면 거래가 이루어지는 것처럼 말입니다.

“가스(gas)” 라는 가상 연료의 1 gas의 가격을 정하는 것은 수요자, 그러니까 사용자입니다. 만약 사용자가 처리할 트랜잭션이 21000 gas가 필요하다고 할 때 사용자는 1 gas에 1원을 지불할 의사를 표시하면, 수수료는 21,000원이 되겠죠? 공급자인 채굴자는 그 가격이 합당하다 생각하면 그 트랜잭션을 처리합니다. 그런데 다른 사용자가 동일한 21000 gas 트랜잭션에 대해 1 gas에 2원을 책정하면 채굴자는 당연히 더 많은 수수료를 내는 트랜잭션을 우선적으로 처리할 것입니다.

다시 말해서 가스비에 따라 어떤 트랜잭션이 더 빠르게 처리될 수도, 또는 더 느리게 처리될 수도 있는 것입니다. 이것은 일종의 “경매”의 형태가 됩니다. 왜냐하면 트랜잭션을 처리해야 하는 다수의 사용자들이 서로 높은 수수료를 부르고 채굴자는 가장 높은 값을 순서대로, 즉 내림차순으로 정렬해서 처리하기 때문입니다. 이러한 경매를 “First Price Auction”이라고 합니다.

그런데 이더리움의 한 블록 내에 담을 수 있는 트랜잭션의 용량을 블록의 “gasLimit”이라는 값으로 제한하고 있기 때문에(현재 1250만 gas) 경우에 따라서는 몇 개 블록 이후에 트랜잭션이 처리될 수도 있습니다. 그래서 가스비가 낮은 트랜잭션들은 수 시간 또는 수 일 동안 기다리는 경우가 생기고, 심지어 처리되지 못하고 취소되기도 합니다.

이렇게 경매 방식으로 트랜잭션이 처리되다 보니 사용자는 사실상 자신의 트랜잭션이 언제 처리될 것인지, 또는 합리적인 가스비가 현재 어느 정도인지 예측하기가 어렵습니다. 물론 현재 네트워크의 상태에 따른 가스비 통계를 참고할 수는 있지만 즉시 처리해야 하는 급한(?) 트랜잭션의 경우는 경쟁때문에 결국 부익부 빈익빈으로 트랜잭션 처리가 이루어질 수 밖에 없습니다. 최근 DeFi 붐이 일어나면서 폭발적으로 증가한 트랜잭션때문에 가스비가 폭등한 것도 그런 이유때문입니다. 보내려는 금액보다 수수료가 더 크다면 분명히 문제가 있는 것입니다.

EIP-1559

그래서 제안된 것이 바로 EIP-1559 입니다. EIP-1559 에서는 사용자 스스로 모든 가스비를 결정하지 않습니다. 대신 프로토콜에 의해 산정된 “protocol-computed” 기본 가스비(base fee)만 내면 트랜잭션 처리가 보장됩니다. 그리고 이 기본 가스비는 채굴자에게 돌아가는 것이 아니라 소각됩니다. 즉 영원히 사라지는 것입니다. 이렇게 함으로써 이더의 인플레이션 억제 효과를 거둘 수 있습니다. 일종의 자사주 매입과 같은 “바이백”이라고 할 수 있습니다.

기본 가스비 소각은 “off-chain”에서 이루어질 수 있는 사용자-채굴자 간의 “이면 합의”에 의한 트랜잭션 처리를 막을 수 있습니다. 이것을 막는 것이 중요한 이유는, 이더리움 프로토콜 차원에서 공용 토큰인 이더가 네트워크 사용료로 지불되는 것이 바람직하기 때문입니다.

블록체인에서는 공용 토큰 외의 수단으로 수수료를 낼 수 있는 것을 “economic abstraction” 이라고 합니다.
The ability to pay for any blockchain transaction and resulting operation(s) with any asset on that blockchain atomically.

EIP-1559 는 최대 블록 gasLimit을 고정하는 것이 아니라 가변적으로 조정하는 것을 제안하고 있습니다. 최근 블록의 크기가 정해진 기준을 넘으면 트랜잭션 수요가 늘어나는 것으로 판단하고 다음 블록의 크기를 늘리는 것입니다. 현재 최대값인 1250만의 두 배인 2500만까지 늘릴 수 있도록 하고 있습니다.

기본 가스비는 이전 블록에 얼마나 많은 가스의 트랜잭션들이 채워져 있는가에 따라 영향을 받습니다. 즉 트랜잭션 처리 수요가 적은 경우는 더 낮게, 많은 경우는 높게 책정됩니다. 예를 들어 이전 블록이 1250만 가스를 초과한다면 다음 블록에서는 약 12.5% 오른 기본 사용료를 내는 식입니다. 사용자는 미리 기본 가스비를 확인할 수 있으므로 자신이 지금 트랜잭션을 보내야 할지 아니면 미룰 지 결정할 수 있습니다.

그런데 이렇게 기본 가스비를 채굴자에게 주지 않고 없애버린다면 채굴자의 이익은 블록 생성 보상밖에 없게 됩니다. 또 블록 용량이 커지면 오히려 늘어나는 트랜잭션을 처리해주는 부담은 채굴자의 몫이므로 손해를 보는 셈입니다. 많은 채굴자들이 트랜잭션을 하나도 저장하지 않은 블록을 만들지도 모릅니다. 이렇게 되면 EIP-1559의 도입이 결과적으로 네트워크의 나쁜 영향을 주지 않을까요?

하지만 수수료 소각은 이더의 소각이므로 인플레이션을 억제하는 효과가 있습니다. 이것은 채굴자들에게도 나쁜 일이 아닙니다. 어차피 이더의 발행은 채굴자들이고 블록보상은 수수료보다 크므로 결과적으로는 이익이 될 수 있습니다. 그리고 블록 보상을 줄여가면서(예를 들어 비트코인의 반감기) 인플레이션을 억제하는 것보다는 블록 보상을 유지하면서 수수료를 소각하는 편이 더 나을 수도 있는 것입니다.

Tip, fee cap

EIP-1559 에서는 기본 가스비에 사용자들이 임의로 “팁”을 추가하여 트랜잭션을 더 빠르게 처리할 수 있는 방안을 제시합니다. 팁은 채굴자들에게 그대로 지급되는 것으로 “First Price Auction” 방식을 그대로 유지하는 것입니다. 더 빠르게 처리해야 하는 상황이란 트랜잭션들이 갑자기 증가하여 네트워크가 정체되는 경우를 말합니다.

“fee cap”은 일종의 수수료 상한이라고 할 수 있는데, 사용자가 원하는 수준의 상한을 정하고 그 이내에서 트랜잭션이 처리될 수 있도록 하는 것입니다. 만약 기본 가스비가 사용자가 설정한 fee cap 보다 크면 트랜잭션을 보내지 않을 것이고 작아지면 그 때 트랜잭션이 처리되는 것입니다.

기본 가스비는 네트워크 상태에 따라 프로토콜에서 결정되고 사용자는 팁과 fee cap을 결정하므로 전체 가스비를 사용자가 결정하는 지금과 비교하면(다른 사용자의 가스비를 전혀 모르는 상태에서) 가스비 예측 가능성이 훨씬 높아진다고 할 수 있겠습니다. 모든 사용자들이 기본 가스비라는 기준을 가지고 현재 수수료를 예측할 수 있게 되는 것입니다.

트랜잭션 처리 수요가 그리 많지 않은 “보통” 상태에서는 대부분 작은 팁만으로도 트랜잭션이 처리될 것이므로 채굴자들에게는 여전히 불리합니다. 물론 기본 가스비 소각으로 인한 인플레이션 억제 효과는 이더리움 네트워크의 모든 참여자들에게는 유리한 것임은 분명합니다.

채굴자들이 일부러 블록의 최대 “gasLimit” 미만으로 트랜잭션을 적게 채워서 블록을 만들 수도 있습니다. 이렇게 되면 블록의 총 가스량은 1250만 미만이 되어 기본 가스비는 매우 작게 책정되고(수요가 적다고 판단), 네트워크의 상태에 상관없이 팁으로 설정한 수수료의 많고 적음에 따라 트랜잭션이 처리될 것입니다. 결과적으로 채굴자들의 집단 행동이 EIP-1559 개선안을 무력화하고 지금과 같은 “First Price Auction” 형태를 그대로 유지하려고 할 지도 모르겠습니다.