The initial Frontier patch is here, and it’s a significant update!
Before proceeding, if your keys originate from Go 1.0 rc or C++ 0.9.36, please be aware that you must regenerate all of your keys IMMEDIATELY. While some versions of the pre-alpha and alpha clients are secure, this is contingent on the specific codebase and version. You should consider all keys created prior to these clients as insecure and compromised. Please note, this does not impact the pre-sale wallets.
Thawing
The thawing pull request has been integrated for the Go client and the Master branch has been revised. If you are operating on release branch 1.0.0, please transition to Master.
Regarding the C++ users, they too can switch to master following the merge, and binaries will be available shortly. If you prefer not to update eth but still intend to contribute to thawing the network, you may simply restart eth with an additional parameter of –gas-floor 3141592.
I also wanted to share a brief explanation on how the gas limit targeting process functions, and why we cannot assure a timeline by which we will hit the 21K limit necessary to handle one fundamental transaction per block.
Every miner operates a copy of geth or eth. In the Frontier Genesis release, both were configured to aim for 5k and maintain that figure. Now, with this update, both clients will be adjusted to target a gas limit of 3M per block.
However, they cannot immediately switch to a 3M gas limit, because the protocol mandates a gradual increase at a specific rate. That rate equals the previous block limit / 1024. Assuming all miners upgrade their clients, and none adjust their settings, we will achieve 3M within 28 hours under a steady 15s block time, including propagation. But here’s the challenge – not all miners will upgrade on time; some may overlook it, and others may never update!
Thus, going forward, if a successful block is mined by an updated miner, the block limit will increase upwards according to the intended rate, but if mined by a ‘lazy’ miner who hasn’t updated, it will revert downwards (as that miner still targets 5k).
For this reason, it will take at least 6 hours to reach a 21K gas limit per block (1 transaction per block), and a minimum of 28 hours to achieve 3M. In practice, it will likely take significantly longer.
This is where the free market comes into action. Technically, miners could have colluded a few days prior to alter the client code and modify the network’s behavior, deviating from our intentions. We merely serve as advisers to the community.
The Genesis block that the community has recognized has now been hardcoded into the clients, so you no longer need to specify the –genesis parameter to initiate eth or geth. Nevertheless, you can still specify a custom genesis block if you want to begin a private chain with a different genesis, for instance.
Bug fixes
On the Go client aspect, a series of bug resolutions and enhancements have been integrated into version 1.0.1, preparing us for a Go 1.5 release.
- Resolved crash in chain manager #1568
- Log number corrections #1545
- Crypto fix for Go 1.5 #1536
- Fix for eth_call and eth_estimateGas #1534
- Console resend method correction #1461
On the C++ client front, a comprehensive external audit has been conducted on its Key Store and cryptographic functions. All suggestions from our expert reviewers have been acted upon. Numerous optimizations and security enhancements have been integrated into the client:
- A distinctive feature of the C++ client is Secure Secrets: all heap memory utilized to store your secrets is securely wiped immediately after use
- The C++ client now utilizes boost::random_device, providing cryptographically secure random-number generation
- Several fixes for crashes and builds for AlethZero
- Enhancements to Alethzero, particularly concerning account information
- The CLI tool ‘ethkey’ can now be utilized alongside AlethZero to inspect and sign an otherwise unsigned transaction. This enables you to maintain a completely air-gapped cold-wallet-device
Difficulty adjustment scheme
Many of you have been curious about how we would implement a transition from PoW to PoS in time for Serenity. This will be managed by the newly established difficulty adjustment scheme, which gracefully secures a hard-fork point in the upcoming 16 months.
It functions as follows: beginning from block 200,000 (approximately 17 days from now), the difficulty will experience an exponential escalation that will only be noticeable in about a year. At that juncture (just around the launch of the Serenity milestone), we will witness a substantial increase in difficulty that will start elevating the block resolution time.
So, a year from now, the network will remain functional for approximately 3-4 months, but will eventually hit a kind of ‘Ice Age’: the difficulty will simply be too high for anyone to discover a block. This will provide us the chance to introduce PoS, possibly via Casper, if it proves effective.
