Here comes the first Frontier patch, and this is a big one!
Before proceeding, if your keys date back to Go 1.0 rc or C++ 0.9.36, please note that you need to regenerate all your keys NOW. Although some versions of the pre-alpha and alpha clients are safe, this depends on the codebase and version. You should assume that all keys generated before these clients are insecure and compromised. This, please note, does not affect pre-sale wallets.
defrost
the thaw pull request has been merged for go customer and the Master branch has been updated. If you are still running the 1.0.0 branch version, switch to Master.
As to C++ users can also switch to master once merged, and the binaries will be available shortly. If you prefer not to update eth but still want to help unfreeze the network, you can also reset eth with an additional parameter of –gas-floor 3141592.
Thought I’d also repost a quick explanation of how the gas limit targeting process works and why we can’t guarantee a time when we’ll hit the 21K limit needed to process a basic transaction per block.
Each miner runs a copy of geth or eth. At the Frontier Genesis release, both were set to target 5k and never deviate from that figure. Now with this update, both clients will be updated to target a gas limit of 3 million per block.
But they can’t just switch to a 3M gas cap, because the protocol forces them to slowly go up at a certain rate. That rate is equal to the previous block limit / 1024. Now assuming all the miners update their clients and none of them mess with the settings, we’re going to hit 3M in 28 hours assuming a constant block time of 15s , including propagation. But here’s the thing: not all miners will update on time, some might be forgotten and some might never update at all!
So, in the future, if a winning block is mined by an upgraded miner, the block cap will be adjusted upwards by the expected rate, but if it is mined by a “lazy” miner who didn’t upgrade, it will be adjusted downwards (since the miner lazy still aiming for 5k).
For this reason, it will take a minimum of 6h to reach a gas limit of 21K per block (1 trx per block), and a minimum of 28h to reach 3M. In practice, it is likely to take much longer than that.
This is where the free market comes into play. Technically, the miners could have even colluded a few days ago to modify the client code and make the network behave quite differently than we had in mind. We are simply acting as advisors to the community.
The Genesis block that we’ve seen adopted by the community has now been hardcoded into clients, and you no longer need to specify the –genesis parameter to start eth or geth. That being said, you can still specify a handmade genesis block if you want to start a private chain with a different genesis, for example.
Error correction
On the Go client side, a number of bug fixes and improvements were merged into 1.0.1, including preparation for the Go 1.5 release.
- Fixed crash in chain manager. #1568
- Correction of registration numbers #1545
- Cryptographic solution for go 1.5 #1536
- Fix for eth_call and eth_estimateGas #1534
- Console Resend method correction #1461
On the C++ client, a full external audit was performed on its Key Store and crypto. All actions recommended by our expert reviewers have been taken into account. Numerous optimizations and security enhancements have been added to the client:
- A unique feature of the C++ client is Secure Secrets: all heap memory used to store your secrets is securely overwritten immediately after it exits.
- The C++ client is now based on boost::random_device, providing cryptographically secure random number generation.
- Various bug fixes and compilation for AlethZero
- Improvements to Alethzero, especially regarding account information
- The ‘ethkey’ CLI tool can now be used in conjunction with AlethZero to inspect and sign an otherwise unsigned transaction. This allows you to have a completely air free cold wallet device
Difficulty Adjustment Scheme
Many of you have been wondering how we would implement a switch from PoW to PoS in time for Serenity. This will be handled by the recently introduced difficulty adjustment scheme, which elegantly guarantees a hard fork point within the next 16 months.
It works as follows: from block 200,000 (very approximately 17 days from now), the difficulty will experience an exponential increase that only noticeable in about a year. At that point (right around the release of the Serenity milestone), we’ll see a significant increase in difficulty that will cause the block resolution time to increase.
So a year later the network will still be useful for about 3-4 months, but eventually it will hit some sort of ‘Ice Age’ – the difficulty will simply be too high for anyone to find a block. This will allow us to introduce PoS, perhaps through Casperif you test yourself.
