In recent days, with various articles at EtherWorld, we've already covered - Metropolis: Ethereum Hardfork, Introduction to Byzantium. Let us quickly drive into another section, exploring more about the phases of Metropolis.

Ethereum's next planned phase Metropolis is a case study into the multidisciplinary, dynamic, inner workings of how the decentralized application platform functions. Ethereum’s developers informed the world regarding the upcoming changes to the Ethereum ecosystem, which is the next milestone release for the Ethereum Platform. The two separate hard forks making up the Metropolis changes will be Byzantium and Constantinople respectively. Both hard forks will gradually introduce major updates to the greater Ethereum ecosystem.

Byzantium will introduce a lot of features. Highlights of the features being implemented are:

● Zk-Snarks
● Account Abstraction.
● Proof of Stake early implementation.
● Flexibility and robustness of smart contracts.

Zk-Snarks - The possibilities of zkSNARKs are impressive, you can verify the correctness of computations without having to execute them and you will not even learn what was executed, just that it was done correctly. Unfortunately, most explanations of zkSNARKs resort to hand-waving at some point and thus they remain something “magical”, suggesting that only the most enlightened actually understand how and why (and if?) they work.

The reality is that zkSNARKs can be reduced to four simple techniques -
a. Encoding as a polynomial problem
b. Succinctness by random sampling
c. Homomorphic encoding / encryption
d. Zero Knowledge

Proof of stake - This protocol will make the entire mining process virtual. In this system, we have validators instead of miners. The way it works is that as a validator, you will first have to lock up some of your ether as stake. After doing that you will then start validating blocks which basically means that if you see any blocks that you think can be appended to the blockchain, you can validate it by placing a bet on it. When and if, the block gets appended, you will get a reward proportional to the stake you have invested. If however, you bet on the wrong or the malicious block, the stake that you have invested will be taken away from you.

Account Abstraction - As part of abstraction, Ethereum is planning to blur the line between its two accounts. Ethereum, as of writing at least, has two accounts. One is the external account, the one controlled by keys that most users are aware of i.e. wallet accounts.

Then you also have the contract account aka the smart contract code in the blockchain. The idea is to essentially allow users to define their external accounts in the form of a smart contract.

Smart Contract - During a contract execution if one wishes to go back to an earlier state during the execution, it would require manual triggering of an exception eg. if one were to cancel a transaction then they will have to double spend to stop it from going through. In order to revert a contract back to its original state developers use the “throw” function. While the throw function does help the contract’s state to go back to the previous one, it eats up all the gas in the contract. To counter this problem, Metropolis is beefing up the “revert” function to help the contracts go back to the previous state without eating up all the gas. The unused gas will be refunded to the contract creator. Along with the revert function, Metropolis is introducing the “returndata” opcode which will enable contracts to return variable sized values.

Constantinople will introduce the following features:

● Abstraction of transaction origin and signature
● Blockhash refactoring

Abstraction of transaction origin and signature - Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.

This can be thought of as a "forwarding contract". It accepts data from the "entry point" address 2**160 - 1 (an account that anyone can send transactions from), expecting that data to be in the format [sig, nonce, to, value, gas price, data]. The forwarding contract verifies the signature, and if the signature is correct, it sets up a payment to the miner and then sends a call to the desired address with the provided value and data.

The benefits that this provides lie in the most interesting cases:

Multisig wallets - Currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees.
Ring signature mixers - The way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins.
Custom cryptography - Users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA.
Non-cryptographic modifications - Users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications.

Ring Signature mixers and Custom Cryptography introduce a feature similar to bitcoin's P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that's a basic functionality that exists in all blockchain protocols today.

Miner and transaction replaying strategy

Note that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current).

One simple strategy is to have a set of regexps that the to address of an account would be checked against, each regexp corresponding to a "standard account type" which is known to be "safe" (in the sense that if an account has that code, and a particular check involving the account balances, account storage and transaction data passes, then if the transaction is included in a block the miner will get paid), and mine and relay transactions that pass these checks.

One example would be to check as follows:

Check that the to address has code which is the compiled version of the Serpent code above, with replaced with any public key hash.
Check that the signature in the transaction data verifies with that key hash.
Check that the gasprice in the transaction data is sufficiently high.
Check that the nonce in the state matches the nonce in the
transaction data.
Check that there is enough ether in the account to pay for the fee.

If all five checks pass, relay and/or mine the transaction.

A looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner's balance is appropriately higher after executing the transaction than before it.

Block chain refactoring

Stores blockhashes in the state, reducing the protocol complexity and the need for client implementation complexity in order to process the BLOCKHASH opcode. Also extends the range of how far back blockhash checking can go, with the side effect of creating direct links between blocks with very distant block numbers, facilitating much more efficient initial light client syncing.

This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols.

Description of light client protocol

We can define a "probabilistic total-difficulty proof" as an RLP list as follows:

[header1, proof1, header2, proof2, ...]

Where each header is a block header, and each proof[i] is a Merkle branch from header[i] to the hash of header[i + 1]. More formally, the proof is an RLP list where each element contains as a substring the hash of the next element, and the last element is the hash of the next header; the elements are taken from the branch of the state tree in header[i] that points to the hash of header[i + 1] that is available in the storage of the BLOCKHASH_CONTRACT_ADDR.

The proof serves to verify that the headers are linked to each other in the given order, and that the given chain has an approximate total difficulty equal to sum(2 ** 256 / mining_result[i]) where mining_result[i] is the result of running the ethash verification function on the given header. A node producing a proof will take case to create a proof that contains as many low-mining-result blocks as possible; a specific algorithm would be to look for all "key blocks" whose mining result is less than 1/50000 of maximum for a valid block allowed by the most recent block difficulty, and then if these blocks do not have a direct connection because they are not an even multiple of 256 or 65536 apart, it would find "glue blocks" to link between them; for example, linking 3904322 to 3712498 might go through 3735552 (multiple of 65536, directly linked in 3904322) and 3712512 (multiple of 256, directly linked in 3735552), and finally 3712512 links directly to 3712498.

For a chain 1 million blocks long, such an algorithm would find 20 key blocks, of which ~1% require zero glue blocks, ~72% require one glue block and ~27% require two glue blocks, so a total sub-chain of ~45 blocks. Each header is ~500 bytes, and each proof will be another ~1500 bytes, so the total size would be ~90 KB.

For news, technical blogs and project updates on Blockchain Technology, please join us at our Website, Facebook, Medium and follow us at Twitter. Please feel free to share this post, and email us your suggestions.