블록체인 개발 블로그

현재 비트코인과 이더리움의 풀 노드를 운영하는데 필요한 디스크 사이즈가 비트코인이 150GB, 400GB 정도로 추정됩니다. 이더리움이 비트코인보다 늦게 시작되었다는 점을 감안하면 이더리움의 디스크 사용량이 빠르게 증가했음을 추측할 수 있습니다. 개인용 랩탑이나 데스크탑의 스토리지 구성이 일반적으로 1TB 이하인 것을 생각해보면 개인이 풀 노드를 운영할 때 부담스럽게 느껴질 수 있는 부분입니다.

그러나 저 수치는 블록체인의 모든 블록과 상태를 저장했을 때 얘기이고, 더 이상 참조할 가능성이 없는 불필요한 정보를 삭제하면 비트코인이 약 5GB, 이더리움이 30GB 수준인 것으로 보입니다. 용량 수치 내용은 아래 2개 링크를 참고했습니다.

https://bitcoin.org/en/full-node#minimum-requirements
https://dev.to/5chdn/the-ethereum-blockchain-size-will-not-exceed-1tb-anytime-soon-58a

비트코인을 예로 들면 새로운 블록을 실행/검증하는데 중요한 것은 블록 내 트랜잭션 Input이 가리키는 Output이 사용 가능한지 여부입니다. 이를 효과적으로 처리하기 위해 비트코인 클라이언트는 UTXO(Unspent Transaction Outputs) set을 관리하며, 신뢰할 수 있는 UTXO set이 있다면 굳이 모든 트랜잭션 히스토리를 저장하고 있지 않더라도 마이닝이 가능합니다. 다만 비교적 최근에 실행된 트랜잭션은 저장하고 있어야 합니다. 블록이 교체될 경우 빠진 블록의 트랜잭션을 되돌리는 과정이 필요하기 때문입니다.

이더리움의 경우 State를 Merkle-Patricia Trie를 통해 상태를 관리하고 루트의 hash를 블록 헤더에 저장합니다. 블록 헤더에 저장되는 내용은 PoW로 보호되기 때문에 특정 State를 다른 노드로부터 통째로 받았을 때 검증해볼 수 있는 항목이 존재하는 장점이 있습니다.

이더리움도 마찬가지로 블록이 교체될 경우를 대비해야 하는데, 비트코인이 트랜잭션을 되돌리는 것과 달리 이더리움은 예전 State 자체를 저장합니다. Trie는 해시포인터 구조로 저장되어 변경되는 경로에 있는 일부 노드만 추가로 저장되기 때문에 효과적인 방법입니다.

리플의 경우 BFT 계열 합의 알고리즘으로 포크가 일어나지 않음을 가정하고 있습니다. 이는 트랜잭션 히스토리를 저장할 필요없이 마지막 State와 해당 State에 대한 합의 내용(서명)만 저장하고 전파하면 됩니다. 리플에서 마지막으로 합의된 상태를 LCL(Last Closed Ledger)라고 부릅니다.

이더리움에서도 PoS 도입을 통해 Block Finality를 보장하면 삭제할 수 있는 정보가 더 늘어나게 됩니다. 리플과 마찬가지로 마지막으로 PoS로 합의한 상태와 합의 내용과 그 검증만 있으면 그 이전의 트랜잭션 및 State는 저장하지 않아도 됩니다. 다만 PoS 합의 내용 자체를 검증하기 위해선 그 전체 히스토리가 필요할 수 있습니다.

최근 이더리움 클라이언트 중 하나인 Parity 구현을 보면서 알게 된 트랜잭션 우선순위와 관련한 내용을 공유하는 글입니다.

코드를 직접 읽어보고자 한다면 링크의 위치부터 시작하셔도 좋을 것 같습니다. Parity는 러스트로 작성되어 있습니다.

이더리움 트랜잭션

이더리움 트랜잭션을 보낼 때에는 5가지를 결정해야 합니다.

- to

- value

- data

- gasprice

- startgas (Gas Limit)

이더리움 트랜잭션에 대해 잘 모르는 분들을 위해 설명하자면, to는 보낼 주소, value는 보낼 이더의 양입니다. data는 contract를 생성하거나 특정 함수를 호출할 때 사용하고, 일반적으로 유저가 직접 입력하진 않습니다. 트랜잭션이 블록에 포함될 때 가스 사용량만큼 마이너에게 수수료를 줘야 하는데, 이와 관련된 필드가 gasprice와 startgas입니다. gasprice는 1 gas 당 지불할 이더입니다. 일반적으로 1~20 Gwei 수준입니다. 참고로 1 Gwei = 0.000000001 ETH 입니다. startgas는 해당 트랜잭션 내에서 허용 할 최대 가스 사용량입니다. 이름이 좀 불만스러운데, 지갑 앱 등에서는 Gas Limit 혹은 Gas 라는 이름이 더 많이 보입니다. 좀 더 직관적인 설명을 위해 Gas Limit이란 표현을 쓰겠습니다.

트랜잭션의 가스 사용량을 예측하기 어렵기 때문에 Gas Limit이라는 개념이 필요합니다. 트랜잭션이 컨트랙트의 함수를 실행시키는 경우 컨트랙트의 상태(state)에 따라 가스 사용량이 달라질 수 있습니다. 트랜잭션을 로컬에서 실행시켜서 100000 Gas가 나왔다 하더라도, 트랜잭션이 마이닝 되기 전에 다른 트랜잭션이 먼저 실행되어 해당 컨트랙트의 상태가 바뀌게 되면 100000 Gas보다 높아질 수도, 낮아질 수도 있습니다. 심지어 컨트랙트가 블록 정보(nonce, 블록 시간, 블록 번호 등)를 쓴다면 마이닝되는 시점에 따라 가스 사용량이 바뀔 수 있습니다.

EVM은 튜링 머신이기 때문에 최악의 경우 무한 루프에 빠져서 가스를 무한정 사용할 가능성도 배제할 수 없습니다. 이 때 가스 사용량이 Limit을 넘게 되면 해당 트랜잭션은 Out of Gas 에러를 내고 실행되지 않습니다. 실행되지 않지만 블록에는 포함되기 때문에 수수료는 발생합니다.

그러나 (아직까지는)스마트 컨트랙트 구현이 방어적이기도 하고, 복잡하지 않기 때문에 의도치 않게 가스를 많이 내게 되는 경우는 잘 없는 것 같습니다. 만약 Gas Limit을 적게 주어 Out of Gas로 수수료만 날릴 일이 생기는 것보단 Gas Limit을 넉넉히 주는 것이 좋을까요?

Parity 클라이언트의 트랜잭션 우선순위 전략

Gas Limit은 트랜잭션에만 있는 것이 아니라 블록에도 존재합니다. 이를 Block Gas Limit이라 하며 비트코인에서의 블록 크기 제한과 같은 역할을 해줍니다. 따라서 마이너는 최대 이익을 위해 최적의 트랜잭션 조합을 선택해야 하는 문제가 있습니다. 이 문제가 0-1 배낭 문제인 것을 인식하면 Gas Price가 높은 순으로 트랜잭션을 뽑는 것이 항상 최적이 아님을 알 수 있습니다. 그렇다고 마이닝 경쟁을 해야하는 시점에 트랜잭션 조합만 계산하고 있을 순 없기 때문에 Gas Price 순으로 뽑는 것도 하나의 방법이긴 합니다. Parity 클라이언트는 Gas Price 순을 포함해 세 가지 우선순위 전략을 가지고 있습니다.

- GasAndGasPrice

- GasFactorAndGasPrice (default)

- GasPriceOnly

GasAndGasPrice와 GasFactorAndGasPrice는 Gas Limit이 낮을 수록 우선순위가 높은 전략입니다. 특히 GasAndGasPrice는 Price보다 Limit를 우선 비교합니다.

GasFactorAndGasPrice는 가중치를 두어서 계산하는 휴리스틱으로 보입니다. transaction_queue.rs의 테스트 코드를 보면 아래처럼 우선순위가 매겨집니다.

테스트 예제의 1순위 트랜잭션이 Gas Price가 가장 낮습니다. 마이너가 트랜잭션을 빨리 포함시켜주길 원한다면 Gas Price 뿐만 아니라 Gas Limit의 설정에도 신경써야 한다는 것을 알 수 있습니다. 즉, 실제 가스 사용량을 정밀하게 예측할 수 있다면 그만큼 Gas Price를 낮게 줄 만한 여지가 있다는 의미입니다.

위의 결과로 봤을 때 GasFactorAndGasPrice가 마이너에게 가장 이익이 되는 전략은 아닐 것으로 보입니다. Parity를 개발하는 입장에선 이더리움 네트워크의 성공 역시 중요하기 때문에 트랜잭션 처리량을 높이는 방향으로 정책을 조정하고 싶었을 것입니다.

마이너들이 실제로 어떤 전략을 주로 취하는지 정확히는 알 수 없으나 etherscan에서 같은 시간대의 블록들의 Gas Price가 10배씩 차이나는 경우가 있는 것을 보면 적어도 블록에 포함되는 요인이 Gas Price만이 아님은 알 수 있습니다.