지난번 스팸공격으로 생긴 뻥 어카운들들 청소하고, 몇가지 문제들을 처리하기 위한 하드포크에 대해 논의를 하고 있습니다.
이미 1,2차로 나누어서 하기로 한 것이라 예정되어 있는 것이기는 하지만, 세부사항들에 대해서는 개발자들간의 이견차이도 좀 있는 것 같습니다.
월요일쯤에 하드포크 날짜가 결정될 듯 합니다.
All Core Devs: Meeting 8
Time: 10/28/2016 1:00PM UTC
- Upcoming HF to clear out state + potentially other changes.
- Clearing out state
- EXP Cost Increase
- EIP 160 by (@vbuterin)
- Replay attack protection
Block number of HF.
EIP/ERC GitHub Organization
- Improvement Discussion
- EIP 148 by @axic
1. Upcoming HF to clear out state + potentially other changes.
Clearing out state
EIP 158 and 161 are now equivalent, after changes were made to 158. 161 will be implemented. Test cases are located here (feel free to add more)(https://etherpad.net/p/EIP158). Currently we have the state bloat because there are many empty accounts. The hard fork will change the database encoding of empty accounts so that they are not present at all anymore, but the encoding only affects accounts that are "touched" by transactions. After the hard fork the Ethereum Foundation will fund the transaction(s) neccessary to clear the empty accounts.
EXP Cost Increase
It was discussed whether a 5x increase in cost was enough. Benchmarks indicated that EXP is 4-8 times underpriced. It was decided that a 5x increase is sufficient for now and it may be increased in the Metropolis hard fork after more analysis. There are ongoing efforts to work on better benchmarking tools which will help determine future OPCODE pricing changes.
Replay attack protection
Three proposals discussed:
- EIP 134 (include a blockhash in an RLP field of each tx)
- EIP 155 (include a
CHAIN_IDas a factor in the
vvalue of the EDCSA signature scheme and in the tx hash)
- EIP 166 (include a
CHAIN_IDin the high-order bits of the tx nonce)
In deciding which replay protection scheme to adopt, the trade-offs between these three proposals were discussed. EIP 134 was rejected because it adds 32 bytes of data to each transaction. Both EIP 155 and EIP 166 were agreed to be equally simple in their implementation complexity, but EIP 166 (which was already provisionally implemented in geth) requires an additional byte of data for each transaction, whereas EIP155 does not add any data to transactions. On the other hand, EIP155 modifies ECDSA signature inputs, and one concern with modifying signature inputs is that when Hardware Security Modules (HSMs) are used for signing transactions, HSM firmware may need to be updated for those transactions to be replay protected. Since EIP 166 does not modify signature inputs, it can be argued that EIP 166 is a "cleaner" separation of concerns. And while the increased data usage of EIP 166 could be remedied with a compression scheme, in the interest of practicality, minimal data usage, and avoiding further postponement of replay protection, core developers' indicated there was a preference for adopting EIP 155 in the upcoming hard fork.
Block number of HF.
Block number for hard fork will be decided on Monday.
2. EIP/ERC GitHub Organization
Hudson and other editors will clean up the EIPs and continue dialog about what to change in the repo.
Future meetings will start being held twice monthly in order to process EIPs more quickly. We will likely have a set time/date (such as every other Monday) to prevent the added complexity of using Doodle's to ask a bunch of people what time works best for them.
Alex Beregszaszi (Solidity), Alex Van de Sande (Mist/Ethereum Wallet), Anton Nashatyrev (ethereumJ), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum), Dan Finlay (MetaMask), Dimitry Khokhlov (cpp-ethereum), Felix Lange (geth), Gavin Wood (EthCore), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Jan Xie (ruby-ethereum & pyethereum), Jeffrey Wilcke (geth), Martin Becze (Research), Péter Szilágyi (geth), Vitalik Buterin (Research & pyethereum)