Automated analysis is the main advantage to working with a modern statically typed compiled language like C++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# The Witness Algorithm: Privacy Protection in a Fully Transparent System | |
By **Vlad Gluhovsky** and **Gavin Wood** | |
# Introduction | |
Being based upon a quasi-Turing-complete (quasi because it's actually bounded) virtual machine, Ethereum is an extremely versatile system. However one of its greatest strengths---universal auditability---seems to lead to a fatal flaw, namely an inescapable lack of privacy. Here we demonstrate an algorithm in order to prove that this is not the case. | |
The algorithm could be used to make an Ethereum contract which, given two sets of addresses sources, `src`, and destinations, `dest`, will guarantee exactly one of two possible eventualities: | |
- For each address in `src`, the controller of that address controls a corresponding address in `dest` (though the two cannot be related *a priori*). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// | |
// The new assembly support in Solidity makes writing helpers easy. | |
// Many have complained how complex it is to use `ecrecover`, especially in conjunction | |
// with the `eth_sign` RPC call. Here is a helper, which makes that a matter of a single call. | |
// | |
// Sample input parameters: | |
// (with v=0) | |
// "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad", | |
// "0xaca7da997ad177f040240cdccf6905b71ab16b74434388c3a72f34fd25d6439346b2bac274ff29b48b3ea6e2d04c1336eaceafda3c53ab483fc3ff12fac3ebf200", | |
// "0x0e5cb767cce09a7f3ca594df118aa519be5e2b5a" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* demonstrating uint overflow and underflow in ethereum solidity | |
this is why you need guards like: | |
if (balances[_to] + _amount < balances[_to]) throw; | |
*/ | |
contract C { | |
// (2**256 - 1) + 1 = 0 | |
function overflow() returns (uint256 _overflow) { | |
uint256 max = 2**256 - 1; | |
return max + 1; | |
} |
Having seen @pirapira's sketch of Bamboo ( https://github.com/pirapira/bamboo/ ), which proposed to add better control about the "smart contract program flow", even across calls, I thought that this should certainly be added to Solidity, and actually, it might even be possible now to a certain degree using inline assembly.
The problem is that with many functions in a contract, it is not always clear which can be called at which stage in the contract's lifetime. Certain smart contracts would be easier to understand if written as follows: