mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Modified introduction-to-smart-contracts.rst
Corrected inline code syntax
This commit is contained in:
parent
981c38b8b0
commit
506191b06c
@ -32,20 +32,20 @@ Storage
|
||||
|
||||
A contract in the sense of Solidity is a collection of code (its functions) and
|
||||
data (its *state*) that resides at a specific address on the Ethereum
|
||||
blockchain. The line `uint storedData;` declares a state variable called `storedData` of
|
||||
type `uint` (unsigned integer of 256 bits). You can think of it as a single slot
|
||||
blockchain. The line :code:`uint storedData;` declares a state variable called :code:`storedData` of
|
||||
type :code:`uint` (unsigned integer of 256 bits). You can think of it as a single slot
|
||||
in a database that can be queried and altered by calling functions of the
|
||||
code that manages the database. In the case of Ethereum, this is always the owning
|
||||
contract. And in this case, the functions `set` and `get` can be used to modify
|
||||
contract. And in this case, the functions :code:`set` and :code:`get` can be used to modify
|
||||
or retrieve the value of the variable.
|
||||
|
||||
To access a state variable, you do not need the prefix `this.` as is common in
|
||||
To access a state variable, you do not need the prefix :code:`this.` as is common in
|
||||
other languages.
|
||||
|
||||
This contract does not yet do much apart from (due to the infrastructure
|
||||
built by Ethereum) allowing anyone to store a single number that is accessible by
|
||||
anyone in the world without (feasible) a way to prevent you from publishing
|
||||
this number. Of course, anyone could just call `set` again with a different value
|
||||
this number. Of course, anyone could just call :code:`set` again with a different value
|
||||
and overwrite your number, but the number will still be stored in the history
|
||||
of the blockchain. Later, we will see how you can impose access restrictions
|
||||
so that only you can alter the number.
|
||||
@ -98,11 +98,11 @@ registering with username and password - all you need is an Ethereum keypair.
|
||||
|
||||
This contract introduces some new concepts, let us go through them one by one.
|
||||
|
||||
The line `address public minter;` declares a state variable of type address
|
||||
that is publicly accessible. The `address` type is a 160 bit value
|
||||
The line :code:`address public minter;` declares a state variable of type address
|
||||
that is publicly accessible. The :code:`address` type is a 160 bit value
|
||||
that does not allow any arithmetic operations. It is suitable for
|
||||
storing addresses of contracts or keypairs belonging to external
|
||||
persons. The keyword `public` automatically generates a function that
|
||||
persons. The keyword :code:`public` automatically generates a function that
|
||||
allows you to access the current value of the state variable.
|
||||
Without this keyword, other contracts have no way to access the variable
|
||||
and only the code of this contract can write to it.
|
||||
@ -117,7 +117,7 @@ get the idea - the compiler figures that out for you.
|
||||
|
||||
.. index:: mapping
|
||||
|
||||
The next line, `mapping (address => uint) public balances;` also
|
||||
The next line, :code:`mapping (address => uint) public balances;` also
|
||||
creates a public state variable, but it is a more complex datatype.
|
||||
The type maps addresses to unsigned integers.
|
||||
Mappings can be seen as hashtables which are
|
||||
@ -127,7 +127,7 @@ too far, though, as it is neither possible to obtain a list of all keys of
|
||||
a mapping, nor a list of all values. So either keep in mind (or
|
||||
better, keep a list or use a more advanced data type) what you
|
||||
added to the mapping or use it in a context where this is not needed,
|
||||
like this one. The accessor function created by the `public` keyword
|
||||
like this one. The accessor function created by the :code:`public` keyword
|
||||
is a bit more complex in this case. It roughly looks like the
|
||||
following::
|
||||
|
||||
@ -140,12 +140,12 @@ single account.
|
||||
|
||||
.. index:: event
|
||||
|
||||
The line `event Sent(address from, address to, uint value);` declares
|
||||
The line :code:`event Sent(address from, address to, uint value);` declares
|
||||
a so-called "event" which is fired in the last line of the function
|
||||
`send`. User interfaces (as well as server appliances of course) can
|
||||
:code:`send`. User interfaces (as well as server appliances of course) can
|
||||
listen for those events being fired on the blockchain without much
|
||||
cost. As soon as it is fired, the listener will also receive the
|
||||
arguments `from`, `to` and `value`, which makes it easy to track
|
||||
arguments :code:`from`, :code:`to` and :code:`value`, which makes it easy to track
|
||||
transactions. In order to listen for this event, you would use ::
|
||||
|
||||
Coin.Sent().watch({}, '', function(error, result) {
|
||||
@ -159,22 +159,22 @@ transactions. In order to listen for this event, you would use ::
|
||||
}
|
||||
}
|
||||
|
||||
Note how the automatically generated function `balances` is called from
|
||||
Note how the automatically generated function :code:`balances` is called from
|
||||
the user interface.
|
||||
|
||||
.. index:: coin
|
||||
|
||||
The special function `Coin` is the
|
||||
The special function :code:`Coin` is the
|
||||
constructor which is run during creation of the contract and
|
||||
cannot be called afterwards. It permanently stores the address of the person creating the
|
||||
contract: `msg` (together with `tx` and `block`) is a magic global variable that
|
||||
contains some properties which allow access to the blockchain. `msg.sender` is
|
||||
contract: :code:`msg` (together with :code:`tx` and :code:`block`) is a magic global variable that
|
||||
contains some properties which allow access to the blockchain. :code:`msg.sender` is
|
||||
always the address where the current (external) function call came from.
|
||||
|
||||
Finally, the functions that will actually end up with the contract and can be called
|
||||
by users and contracts alike are `mint` and `send`.
|
||||
If `mint` is called by anyone except the account that created the contract,
|
||||
nothing will happen. On the other hand, `send` can be used by anyone (who already
|
||||
by users and contracts alike are :code:`mint` and :code:`send`.
|
||||
If :code:`mint` is called by anyone except the account that created the contract,
|
||||
nothing will happen. On the other hand, :code:`send` can be used by anyone (who already
|
||||
has some of these coins) to send coins to anyone else. Note that if you use
|
||||
this contract to send coins to an address, you will not see anything when you
|
||||
look at that address on a blockchain explorer, because the fact that you sent
|
||||
@ -301,7 +301,7 @@ If the target account contains code, that code is executed and
|
||||
the payload is provided as input data.
|
||||
|
||||
If the target account is the zero-account (the account with the
|
||||
address `0`), the transaction creates a **new contract**.
|
||||
address :code:`0`), the transaction creates a **new contract**.
|
||||
As already mentioned, the address of that contract is not
|
||||
the zero address but an address derived from the sender and
|
||||
its number of transaction sent (the "nonce"). The payload
|
||||
@ -323,7 +323,7 @@ the transaction and to pay for this execution. While the EVM executes the
|
||||
transaction, the gas is gradually depleted according to specific rules.
|
||||
|
||||
The **gas price** is a value set by the creator of the transaction, who
|
||||
has to pay `gas_price * gas` up front from the sending account.
|
||||
has to pay :code:`gas_price * gas` up front from the sending account.
|
||||
If some gas is left after the execution, it is refunded in the same way.
|
||||
|
||||
If the gas is used up at any point (i.e. it is negative),
|
||||
@ -410,7 +410,7 @@ Delegatecall / Callcode and Libraries
|
||||
There exists a special variant of a message call, named **delegatecall**
|
||||
which is identical to a message call apart from the fact that
|
||||
the code at the target address is executed in the context of the calling
|
||||
contract and `msg.sender` and `msg.value` do not change their values.
|
||||
contract and :code:`msg.sender` and :code:`msg.value` do not change their values.
|
||||
|
||||
This means that a contract can dynamically load code from a different
|
||||
address at runtime. Storage, current address and balance still
|
||||
@ -452,9 +452,9 @@ Selfdestruct
|
||||
============
|
||||
|
||||
The only possibility that code is removed from the blockchain is
|
||||
when a contract at that address performs the `SELFDESTRUCT` operation.
|
||||
when a contract at that address performs the :code:`SELFDESTRUCT` operation.
|
||||
The remaining Ether stored at that address is sent to a designated
|
||||
target and then the storage and code is removed.
|
||||
|
||||
Note that even if a contract's code does not contain the `SELFDESTRUCT`
|
||||
Note that even if a contract's code does not contain the :code:`SELFDESTRUCT`
|
||||
opcode, it can still perform that operation using delegatecall or callcode.
|
||||
|
Loading…
Reference in New Issue
Block a user