Insights from WS with Christoph Jentzsch
This week I had the opportunity to partake at a workshop with Christoph Jentzsch from Slock.it and pick his brain. What have I learned? Most of all Christoph has stamina, being able to uphold a high level of energy during eight hours of lecture and continuous fire of questions and discussion. Second a lot of technical details about the Ethereum blockchain became a lot clearer. Here are my fresh insights.
Blockchain details
Talking about fundamentals of the Ethereum blockchain I finally understood that the synchronization process is replaying the whole history of transactions and saving it to the state tree. It was a Deja Vue like moment because I employed the technique of event streaming and event stores with the architectural pattern Command Query Responsibility Segregation (CQRS) successfully in the past.
Sharding enables concurrency
I was eager to learn how Serenity and Metropolis will potentially impact Smart Contract development. Obviously because changes partake in the lower layers of the blockchain, not very much. The only effect on Smart Contracts would be due to sharding: multiple shards would allow for of concurrent execution of contracts. If this is purely a threat to consistency or if there are some advantages you could leverage is not clear to me.
ZKSNARK / Ring Signature as native contracts
I was very interested in privacy preserving features as they are very important to my customers. Zcash’s Electric Coin Company will continue to work on ZKSNARKS for Ethereum. Zero knowledge proofs functionality and ring signature probably will be deployed as precompiled contracts, i.e. not running on the EVM but native.
Smart contract patterns
Some useful smart contract patterns we discussed:
Dynamic function calls via `call.value(money)(data)`
Probably a classic for most advanced Solidity programmers. This requires some low level tweaking of binary information in the data section. First you store the function signature, then the first parameter etc. The easiest way to get the fully parametrized function call data is via getData():
// Get the call data, so you can call the contract through some other means var myCallData = myContractInstance.myMethod.getData(param1 [, param2, …]);
// myCallData = ‘0x45ff3ff6000000000004545345345345..’see http://ethereum.stackexchange.com/a/5670/264
Generic Library
Another pattern is the generic library. It allows to add arbitrary functions after the deployment of a contract.
Through one level of indirection you can exchange library versions that use the delegatecall opcode
TK unfortunately I cant find an example at the moment. Will update asap
Thawing Phase
A clever trick to have some control over the blockchain is to have a thawing phase where a certain address is in control over some critical functionality like freezing the contract. Think emergency modifier who always throws if on.
If thawing ends the admin/owner can set the controlling address to an unknown address like 0x0000000000000000000and effectively burn their control over the contract.
There is a backdoor to pay ether to a contract who has no payable modifier set: suicide(contractAddr). This is because suicide does not send a transaction, but just updates the amount in control of the given address, hence payable is never checked.
Outlook and a big ?
So what will change in the future on Ethereum? Christoph believes there will be more on chain governance, more control over network parameters through smart contracts. For example the gas prices need to be adapted constantly to price the costs of storage and computation right. This has been shown by the autumn DoS attacks.
Yet: somehow it doesn’t feel right to me, the idea breaks one of the fundamental design patterns of software development: layering. The application layer suddenly bears variables that are required by the EVM. Circular references are now possible. There is no isolation anymore of lower layers from the upper layers. This increases bugs and security risks. What does the reader think?
