solidity/docs/common-patterns.rst

354 lines
10 KiB
ReStructuredText
Raw Normal View History

2015-12-07 20:16:25 +00:00
###############
Common Patterns
###############
2016-07-08 16:21:57 +00:00
.. index:: withdrawal
2016-07-09 23:01:27 +00:00
.. _withdrawal_pattern:
2016-07-08 16:21:57 +00:00
*************************
Withdrawal from Contracts
*************************
The recommended method of sending funds after an effect
2016-07-11 14:28:20 +00:00
is using the withdrawal pattern. Although the most intuitive
method of sending Ether, as a result of an effect, is a
2016-07-08 16:21:57 +00:00
direct ``send`` call, this is not recommended as it
introduces a potential security risk. You may read
more about this on the :ref:`security_considerations` page.
This is an example of the withdrawal pattern in practice in
a contract where the goal is to send the most money to the
2016-08-12 15:03:58 +00:00
contract in order to become the "richest", inspired by
`King of the Ether <https://www.kingoftheether.com/>`_.
2016-07-08 16:21:57 +00:00
In the following contract, if you are usurped as the richest,
2017-03-16 11:20:39 +00:00
you will receive the funds of the person who has gone on to
2016-08-11 18:34:36 +00:00
become the new richest.
2016-07-11 19:34:46 +00:00
::
2016-07-11 19:34:46 +00:00
2017-04-19 18:12:45 +00:00
pragma solidity ^0.4.11;
contract WithdrawalContract {
address public richest;
uint public mostSent;
2016-07-11 19:34:46 +00:00
2016-08-12 15:07:02 +00:00
mapping (address => uint) pendingWithdrawals;
2016-08-11 18:34:36 +00:00
2016-09-05 14:29:08 +00:00
function WithdrawalContract() payable {
richest = msg.sender;
mostSent = msg.value;
2016-07-08 16:21:57 +00:00
}
2016-09-05 14:29:08 +00:00
function becomeRichest() payable returns (bool) {
if (msg.value > mostSent) {
2016-08-12 15:07:02 +00:00
pendingWithdrawals[richest] += msg.value;
richest = msg.sender;
mostSent = msg.value;
2016-08-10 15:11:13 +00:00
return true;
2016-08-24 19:28:07 +00:00
} else {
2016-08-10 15:11:13 +00:00
return false;
}
2016-07-08 16:21:57 +00:00
}
function withdraw() {
2016-08-12 15:07:02 +00:00
uint amount = pendingWithdrawals[msg.sender];
// Remember to zero the pending refund before
// sending to prevent re-entrancy attacks
pendingWithdrawals[msg.sender] = 0;
msg.sender.transfer(amount);
2016-07-11 19:34:46 +00:00
}
}
2016-07-11 19:34:46 +00:00
2016-09-05 14:29:08 +00:00
This is as opposed to the more intuitive sending pattern:
2016-07-11 19:34:46 +00:00
::
2016-07-11 19:34:46 +00:00
2017-04-19 18:12:45 +00:00
pragma solidity ^0.4.11;
contract SendContract {
address public richest;
uint public mostSent;
2016-08-11 18:34:36 +00:00
2016-09-05 14:29:08 +00:00
function SendContract() payable {
richest = msg.sender;
mostSent = msg.value;
2016-07-08 16:21:57 +00:00
}
2017-02-21 19:44:18 +00:00
function becomeRichest() payable returns (bool) {
if (msg.value > mostSent) {
// This line can cause problems (explained below).
2017-04-19 18:12:45 +00:00
richest.transfer(msg.value);
richest = msg.sender;
mostSent = msg.value;
2016-08-10 15:11:13 +00:00
return true;
2016-08-24 19:28:07 +00:00
} else {
2016-08-10 15:11:13 +00:00
return false;
}
2016-07-08 16:21:57 +00:00
}
}
Notice that, in this example, an attacker could trap the
2016-08-11 18:34:36 +00:00
contract into an unusable state by causing ``richest`` to be
the address of a contract that has a fallback function
which fails (e.g. by using ``revert()`` or by just
conssuming more than the 2300 gas stipend). That way,
whenever ``transfer`` is called to deliver funds to the
"poisoned" contract, it will fail and thus also ``becomeRichest``
will fail, with the contract being stuck forever.
In contrast, if you use the "withdraw" pattern from the first example,
the attacker can only cause his or her own withdraw to fail and not the
rest of the contract's workings.
2016-07-08 16:21:57 +00:00
2015-12-07 20:16:25 +00:00
.. index:: access;restricting
******************
Restricting Access
******************
Restricting access is a common pattern for contracts.
Note that you can never restrict any human or computer
from reading the content of your transactions or
your contract's state. You can make it a bit harder
by using encryption, but if your contract is supposed
to read the data, so will everyone else.
You can restrict read access to your contract's state
by **other contracts**. That is actually the default
unless you declare make your state variables ``public``.
2015-12-07 20:16:25 +00:00
Furthermore, you can restrict who can make modifications
to your contract's state or call your contract's
functions and this is what this page is about.
.. index:: function;modifier
The use of **function modifiers** makes these
restrictions highly readable.
::
2017-04-19 18:12:45 +00:00
pragma solidity ^0.4.11;
2015-12-07 20:16:25 +00:00
contract AccessRestriction {
// These will be assigned at the construction
// phase, where `msg.sender` is the account
// creating this contract.
address public owner = msg.sender;
uint public creationTime = now;
// Modifiers can be used to change
// the body of a function.
// If this modifier is used, it will
// prepend a check that only passes
// if the function is called from
// a certain address.
modifier onlyBy(address _account)
{
2017-04-19 18:12:45 +00:00
require(msg.sender == _account);
2016-09-05 12:54:50 +00:00
// Do not forget the "_;"! It will
2015-12-07 20:16:25 +00:00
// be replaced by the actual function
2016-09-05 14:29:08 +00:00
// body when the modifier is used.
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
}
/// Make `_newOwner` the new owner of this
/// contract.
function changeOwner(address _newOwner)
onlyBy(owner)
{
owner = _newOwner;
}
modifier onlyAfter(uint _time) {
2017-04-19 18:12:45 +00:00
require(now >= _time);
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
}
/// Erase ownership information.
/// May only be called 6 weeks after
/// the contract has been created.
function disown()
onlyBy(owner)
onlyAfter(creationTime + 6 weeks)
{
delete owner;
}
// This modifier requires a certain
// fee being associated with a function call.
// If the caller sent too much, he or she is
// refunded, but only after the function body.
2016-09-05 14:29:08 +00:00
// This was dangerous before Solidity version 0.4.0,
// where it was possible to skip the part after `_;`.
2015-12-07 20:16:25 +00:00
modifier costs(uint _amount) {
2017-04-19 18:12:45 +00:00
require(msg.value >= _amount);
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
if (msg.value > _amount)
2016-08-16 14:26:57 +00:00
msg.sender.send(msg.value - _amount);
2015-12-07 20:16:25 +00:00
}
function forceOwnerChange(address _newOwner)
costs(200 ether)
{
owner = _newOwner;
// just some example condition
if (uint(owner) & 0 == 1)
2016-09-05 14:29:08 +00:00
// This did not refund for Solidity
// before version 0.4.0.
2015-12-07 20:16:25 +00:00
return;
2016-09-05 14:29:08 +00:00
// refund overpaid fees
2015-12-07 20:16:25 +00:00
}
}
A more specialised way in which access to function
calls can be restricted will be discussed
in the next example.
.. index:: state machine
*************
State Machine
*************
Contracts often act as a state machine, which means
that they have certain **stages** in which they behave
differently or in which different functions can
be called. A function call often ends a stage
and transitions the contract into the next stage
(especially if the contract models **interaction**).
It is also common that some stages are automatically
reached at a certain point in **time**.
An example for this is a blind auction contract which
starts in the stage "accepting blinded bids", then
transitions to "revealing bids" which is ended by
2017-04-14 03:57:14 +00:00
"determine auction outcome".
2015-12-07 20:16:25 +00:00
.. index:: function;modifier
Function modifiers can be used in this situation
to model the states and guard against
incorrect usage of the contract.
Example
=======
In the following example,
the modifier ``atStage`` ensures that the function can
2015-12-07 20:16:25 +00:00
only be called at a certain stage.
Automatic timed transitions
are handled by the modifier ``timeTransitions``, which
2015-12-07 20:16:25 +00:00
should be used for all functions.
.. note::
**Modifier Order Matters**.
If atStage is combined
with timedTransitions, make sure that you mention
it after the latter, so that the new stage is
taken into account.
Finally, the modifier ``transitionNext`` can be used
2015-12-07 20:16:25 +00:00
to automatically go to the next stage when the
function finishes.
.. note::
**Modifier May be Skipped**.
2016-09-05 14:29:08 +00:00
This only applies to Solidity before version 0.4.0:
2015-12-07 20:16:25 +00:00
Since modifiers are applied by simply replacing
code and not by using a function call,
the code in the transitionNext modifier
can be skipped if the function itself uses
return. If you want to do that, make sure
2016-09-05 14:29:08 +00:00
to call nextStage manually from those functions.
Starting with version 0.4.0, modifier code
2016-08-16 14:26:57 +00:00
will run even if the function explicitly returns.
2015-12-07 20:16:25 +00:00
::
2017-04-19 18:12:45 +00:00
pragma solidity ^0.4.11;
2015-12-07 20:16:25 +00:00
contract StateMachine {
enum Stages {
AcceptingBlindedBids,
RevealBids,
AnotherStage,
AreWeDoneYet,
Finished
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
// This is the current stage.
Stages public stage = Stages.AcceptingBlindedBids;
uint public creationTime = now;
modifier atStage(Stages _stage) {
2017-04-19 18:12:45 +00:00
require(stage == _stage);
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
function nextStage() internal {
stage = Stages(uint(stage) + 1);
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
// Perform timed transitions. Be sure to mention
// this modifier first, otherwise the guards
// will not take the new stage into account.
modifier timedTransitions() {
if (stage == Stages.AcceptingBlindedBids &&
now >= creationTime + 10 days)
nextStage();
if (stage == Stages.RevealBids &&
now >= creationTime + 12 days)
nextStage();
// The other stages transition by transaction
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
}
2016-05-13 14:32:35 +00:00
2015-12-07 20:16:25 +00:00
// Order of the modifiers matters here!
function bid()
2016-09-05 14:29:08 +00:00
payable
2015-12-07 20:16:25 +00:00
timedTransitions
atStage(Stages.AcceptingBlindedBids)
{
// We will not implement that here
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
function reveal()
timedTransitions
atStage(Stages.RevealBids)
{
}
// This modifier goes to the next stage
// after the function is done.
modifier transitionNext()
{
2016-09-05 12:54:50 +00:00
_;
2015-12-07 20:16:25 +00:00
nextStage();
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
function g()
timedTransitions
atStage(Stages.AnotherStage)
transitionNext
{
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
function h()
timedTransitions
atStage(Stages.AreWeDoneYet)
transitionNext
{
}
2016-05-18 15:05:28 +00:00
2015-12-07 20:16:25 +00:00
function i()
timedTransitions
atStage(Stages.Finished)
{
}
}