openzeppelin / openzeppelin-contracts Goto Github PK

Pulling zeppelin-solidity into a project does not support any visibility into which version of zeppelin-solidity is actually being used

It might be helpful to provide a set of "adversarial" contracts that would help people write tests for common bugs and vulnerabilities. Some ideas:

• A contract that pushes the call stack down to 1023 frames before calling some other function
• A contract that responds in weird/nonstandard ways to being sent a transaction
• A contract that uses reentrancy to try to break things?

Not sure how easy it would be to implement these flexibly and reusably. It might require first-class functions.

See Simple Swaps and Unsigned Integers in http://vessenes.com/advice-for-dao-2-0s/

The idea is to create a contract for fund management that is separate from other contract/business logic. In this way, we can define clear interfaces for dealing with funds and reduce the attack surface on contracts managing funds.

Idea from https://youtu.be/1D7BH8krdhQ?t=11m54s

Some of this is already present in Ownable.sol, but needs more thought

See: https://github.com/federicobond/ethereum-paypub/blob/d8abdcb118e3c75203f44f5097ca2a878f8a77a8/test/paypub.js#L21

Thanks @federicobond for idea

Many crowdsales use stepped price functions. Add a tested and well-written implementation

e.g: https://github.com/makoto/blockparty

Idea based on FirstBlood's token: https://github.com/Firstbloodio/token/blob/2ee2fccb4d111bee461de569bf792619cab40650/smart_contract/FirstBloodToken.sol#L228

Provide a mechanism for contracts to validate external auth mechanisms such as verifying an EC signature before proceeding with the function.

We should probably make the Bounty contracts more generic, instead of having a separate file for each contract.

Do you all have any thoughts on Condition Oriented Programming? I've seen a couple places where branching logic is in the methods, most often something like if (foo) throw;. Which still seems like it could be pulled out into modifiers. Does Zeppelin have any stance on this pattern?

It definitely requires more code, and could be more expensive. But on the positive side, there is cleaner separation of concerns, limited complexity, and I think the expressiveness that comes with naming modifiers is very valuable.

See Pause in http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

Missing:

• Killable
• SafeMath
• Shareable #91
• DayLimit #92
• MultisigWallet #93

Throwing this idea out there for discussion

See VersionUpgrade, Deprecate and MostRecentVersionAddress in http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

Implement function modifiers that only allow calls from a whitelist of addresses/contracts
See Whitelist at http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

See: http://hackingdistributed.com/2016/07/11/decentralized-escape-hatches-for-smart-contracts/

Idea from: http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

Many blockchain wallet transfers that were problematic would have been much less so if there were a one week waiting period. Such a thing is easy to implement in Ethereum and could radically improve security.

Maybe this contract should be called DelayedClaimable, and should inherit from Claimable

The Solidity style guide recommends a 2 line separation between top level declarations, so we should format files like this:

pragma solidity ^0.4.4;


import "../MyImport.sol";


/*
 * MyContract
 * Here goes the contract description
 */
contract MyContract {
  ...
}

Setup travis CI or some CI tool to automatically run tests on each PR.

Refactor Gavin's multisig wallet code (https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol) into one or more Zeppelin-style multisig contracts

Contracts want to send periodic or timed payments. E.g: "send x ether to this address every week for 5 weeks". Or "Send x ether to this address in 10 days".

We should write a contract that does that securely

Current Solidity code reuse is based on copy-pasting or downloading existing code from other repositories. Mature ecosystems have good code repository management systems such as NodeJS’ npm or Ruby’s gems.
An interesting variation in Ethereum is the possibility of reusing code already deployed to the blockchain. Let's build tools that allow to easily link your contracts to deployed libraries.

See NaturalDeath section in http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

$ npm i zeppelin-solidity

[email protected] install C:\projects\truffle-dapps\coinmaker\node_modul es\zeppelin-solidity
scripts/install.sh

'scripts' is not recognized as an internal or external command,
operable program or batch file.
npm WARN enoent ENOENT: no such file or directory, open 'C:\projects\truffle-dap ps\coinmaker\package.json'
npm WARN coinmaker No description
npm WARN coinmaker No repository field.
npm WARN coinmaker No README data
npm WARN coinmaker No license field.
npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Users\Rocky\AppData\ Roaming\npm\node_modules\npm\bin\npm-cli.js" "i" "zeppelin-solidity"
npm ERR! node v6.7.0
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: scripts/install.sh
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script 'scripts/install.s h'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the zeppelin-solidity pac kage,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! scripts/install.sh
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs zeppelin-solidity
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls zeppelin-solidity
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! C:\projects\truffle-dapps\coinmaker\npm-debug.log

Rocky@ASUS MINGW64 /c/projects/truffle-dapps/coinmaker
$ node --version
v6.7.0

Rocky@ASUS MINGW64 /c/projects/truffle-dapps/coinmaker
$ npm --version
3.10.8

See "Remediation Approach 2: Mutexes" section here:
http://vessenes.com/more-ethereum-attacks-race-to-empty-is-the-real-deal/

See "Contact" section in http://vessenes.com/we-need-some-best-practices-for-smart-contracts/

An important part of smart contract development is how to interact with off-blockchain data sources.

An interesting idea to explore is to do inversion of control, where oracles call contracts (to communicate outside truths) through a common interface method, and can implement their oracle logic as wanted: trusted expert, closed voting, open voting, API wrapper.
Instead of contracts requesting data from oracles, oracles inform contracts of data changes.

Lots of security problems (including the infamous TheDAO hack) can be prevented by using a pull payment strategy (as opposed to pushing payments with send).

We already have a simple PullPayment contract, but more comprehensive tools, documentation and examples are needed.

A simple idea is to create a subclass of PullPayment that allows sending money to all pending payees at once.

I'm opening this issue to collect resources and ideas on formal verification on Zeppelin contracts.

I'll start with this paper, which uses F* to formally verify Solidity contracts:
http://research.microsoft.com/en-us/um/people/nswamy/papers/solidether.pdf

Scenario: you create a small crowdsale for your widget and it becomes really popular very quickly. Now there is a million dollar price tag on the poorly secured private key you used to deploy your contract and you start sleeping badly at night. Nobody worth their salt would secure a million dollars in a hot wallet.

Luckily, you remember that your contract inherits from Superuser, so next morning you generate a key in cold storage and take note of its address. You then use your owner account to configureSuperuser(address) and your sleep improves again because any sensitive method is using the requireSuperuser modifier. This modifier ensures that msg.sender is the superuser or (in case no superuser is configured, the owner). BOOM! Upgradeable security and peace of mind.

I will have a working implementation later today. Feel free to leave any feedback.

UPDATE: As was pointed out in the Slack channel, this is not a good example, as you can just transfer the ownership of the contract. A better example is when you want to keep a hot key for performing managerial actions but have a cold storage key as superuser in case the hot key is compromised.

See https://github.com/duaraghav8/Solium

http://fc16.ifca.ai/bitcoin/papers/MES16.pdf

All tests should instantiate new contracts unless it's strictly necessary to use deployed versions.

See Transfer of Contract Ownership in http://vessenes.com/we-need-some-best-practices-for-smart-contracts/