며칠간 이더리움의 네트워크에 대한 이슈가 생겨서 많은 일들이 있었습니다.
제일 큰것이 TxID 의 실종이었습니다.
저도 Status.im 참여로 새벽 4시까지 미스트를 붙잡고 있었고,
다음날까지도 계속해서 전송 시도를 했습니다.
그리고 전송 으로 생긴 TxID는 Pending 이후 사라지거나, Opcode 에러로 ICO에 참여하지 못했습니다.
TxID의 실종은 사실 Bancor ICO 때에도 있었습니다.
뱅커 ICO 당시에도 저는 3번만에 성공을 했었고, TxID 도 증발했었습니다.
그 때에도 있었지만 이제 크게 대두 되었던 까닭은 뭘까요?
Status ICO 로 인한 네트워크 부하 -> 실패한 사람들의 재시도로 부하 가중
-> 그로인한 TxID 실종 -> 거래소에서의 상태와 이더 네트워크의 상태의 상이함
ICO로 인한 부하는 이미 예전부터 나오던 얘기였습니다.
스테이터스 ICO 에서 최대의 부하를 맞이했습니다.
사람들끼리 돈을 내면서 자의로 DDos를 했다는 우스갯 소리가 나올정도로 말입니다
ICO 도 Dynamic Ceiling (아직 정확하게 파악은 못했습니다 ^^;;) 으로 인해 하루정도가 소요되어서야 끝나게 되었습니다.
하루동안 계속 된 Pending Tx 들로 결국 이더리움 네트워크의 부하는 계속 됐습니다.
그러면 네트워크의 부하의 원인은 많은 트랙잭션인것은 밝혀졌는데
왜 TxID는 사라지게 되었을까요?
네트워크 부하가 심해지고 22일 INFURA 에서는 하나의 글을 올렸습니다.
when-there-are-too-many-pending-transactions
팬딩 트랙잭션이 많아지고 왜 트랜잭션들이 사라지게 되었는가.
Ethereum client to store pending transactions before they are mined (Geth calls it the “transaction pool”; Parity calls it the “transaction queue”).
-> 이더리움 클라이언트는 Geth 에서는 "transaction pool", Parity 에서는 "transaction queue" 라고 불리는 마이닝을 하기 전의 팬딩 트랙잭션을 가지고 있습니다.
그리고 Geth의 해당 소스는 다음과 같습니다.
// TxPoolConfig are the configuration parameters of the transaction pool.
type TxPoolConfig struct {
PriceLimit uint64 // Minimum gas price to enforce for acceptance into the pool
PriceBump uint64 // Minimum price bump percentage to replace an already existing transaction (nonce)
AccountSlots uint64 // Minimum number of executable transaction slots guaranteed per account
GlobalSlots uint64 // Maximum number of executable transaction slots for all accounts
AccountQueue uint64 // Maximum number of non-executable transaction slots permitted per account
GlobalQueue uint64 // Maximum number of non-executable transaction slots for all accounts
Lifetime time.Duration // Maximum amount of time non-executable transaction are queued
}
// DefaultTxPoolConfig contains the default configurations for the transaction
// pool.
var DefaultTxPoolConfig = TxPoolConfig{
PriceLimit: 1,
PriceBump: 10,
AccountSlots: 16,
GlobalSlots: 4096,
AccountQueue: 64,
GlobalQueue: 1024,
Lifetime: 3 * time.Hour,
}
1024개의 마이닝 되지 않은(팬딩) 트랜잭션을 가질수 있고, 그 이상의 트랜잭션이 발생해서 마이너들에게 전해지지 않게 되고
결국 전달되지 못한 트랜잭션들은 사라지게 되는 겁니다.
이더리움 네트워크 개발을 할 때에도 이정도의 부하가 생길지는 몰랐겠죠.
현재 마이너들이 가질 수 있는 큐(팬딩을 가지는 개수)의 크기를 늘리려고 하고 있습니다.
이더리움의 인기가 결국 이더리움 네트워크를 부하를 가지고 오게 되는 기이한 현상
참 신기한 현실입니다.
이어서 TxID의 증발이 크게 대두 된 이야기도 써내려가보겠습니다
다음글 : 며칠간의 이더리움 상황 - 2
Donation
기부는 사랑입니다.
- Ƀ BTC : 16MdVNJgvGYbVuaC6KrjGNy2RCrNsaPaZz
- Ξ ETH : 0x5debb97a6Cc1Fdf686a3C6aA804a623a21deD73c
개발자에게 Starize 도 사랑입니다.