When wil be relise on Frontier?
So, the second question, why when i mining with ethminer my hard was load 100%?
Same question actually (found answer), Frontier is in testing stages and the testnet is showing progress.
https://stats.ethdev.comBlog post from the 15th
https://blog.ethereum.org/2015/06/15/another-ethereum-d%CE%BEv-update/We continue our preparations for the Frontier release. While were still uncertain of the precise release date, we are becoming increasingly happy at the resilience of the Olympic testnet. As the Olympic testnets failure was ongoing, the adversity caused some reflection over how we might mitigate such problems in the future. The depth and duration of the consensus failure can, roughly speaking, be put down to two problems: firstly that there was a bug in the Go codebase causing it to accept invalid blocks (in this case, blocks with an invalid proof-of-work nonce); secondly that there was a huge problem with upgrading the network since miners continued to mine on the bad chain and were slow to upgrade their nodes so that they mined on the correct chain. Essentially, the first was a forensic problem and the second an problem of organisation.
To make sure this is never so deep nor broad in the future, I designed two new protocols: the Bad Chain Canary and the Bad Block Reporting API. The bad chain canary is a simple contract. It is controlled by a single key (though there may be several of them) and sits quietly until poked by its owner. I will be one such owner, Vitalik and Jeff two others and there will likely be fourth, Christoph. When poked, it is given a blockhash and block number pair; this pair refers to a recent block on a bad chain. If they match the chain that the contract thinks it is sitting on, it puts itself in the bad chain state. This allows the Ethereum core devs to inform everyone who is running a client on a bad chain (i.e. one that does not conform to the Yellow Paper due to a bug) that it is such. The default in clients (easily overridden) is not to mine on such chains (since to do so would be a waste of energy), but rather to inform the user that they should upgrade at their earliest opportunity.
The Bad Block Reporting API is a simple JSON RPC that allows a number of our nodes to run in a sentinel mode. In this mode, if they come across a bad block, they automatically compile a standardised report of what went wrong including expected transaction receipts, VM traces, proof-of-work and block error information. This report is then instantly sent to a ÐΞV server where it can trigger an early warning system and, should the release tzar (thatd be Taylor) deem it necessary, alert the core devs. Through standardisation and usage of a simple format, its designed so that we can easily code up a JSON-comparison engine to quickly diagnose where the consensus issue lies.
One future job is to combine the two so that the JSON-RPC can also manage the reporting of canary information in this case, a user may set up a sentinel server to give them an email whenever the contract reports that mining has ceased and/or they should upgrade their node to continue mining.
