You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/source/smart-contracts.md
+21-26Lines changed: 21 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,14 @@
1
1
# Smart contracts
2
2
3
3
This document explains how to work with smart contracts. First we'll establish the mental model of working with
4
-
blockchains. If you are already familiar with the NEO blockchain or talking to smart contracts on blockchains in general
4
+
blockchains. If you are already familiar with the EpicChain blockchain or talking to smart contracts on blockchains in general
5
5
you can go directly to the [interaction section](#interacting-with-smart-contracts). Next we'll look have a what comes
6
6
in to play in a basic smart contract interaction. Followed by that we build an understanding of how the wrappers work
7
7
before diving into the breakdown of a NEP-17 token transfer where all learned comes together.
8
8
9
9
After reading this chapter you'll have an understanding of the major components involved in interacting with smart
10
10
contracts. You be able to do all common interactions with a smart contract of choice and have the foundational knowledge
11
-
that allows you to follow the [examples](https://github.com/CityOfZion/neo-mamba/tree/master/examples) on the Github repo.
11
+
that allows you to follow the [examples](https://github.com/epicchainlabs/Python-SDK-for-the-EpicChain-blockchain/tree/main/examples) on the Github repo.
12
12
13
13
## What are smart contracts?
14
14
@@ -18,7 +18,7 @@ tokens, executing some algorithm or just reading stored data is up to the contra
18
18
that the smart contract code does not live on your machine and is executed on a remote network (the blockchain).
19
19
20
20
Add to this that smart contracts are "compiled" to a custom language and executed by a custom processor
21
-
(the NEO Virtual Machine). That means that your Python code cannot talk Python to the smart contract, but that a
21
+
(the EpicChain Virtual Machine). That means that your Python code cannot talk Python to the smart contract, but that a
22
22
translation has to happen. This library performs that translation under the hood and helps communicate between your
23
23
machine and the smart contract.
24
24
@@ -28,23 +28,20 @@ There are 2 layers in this library used to talk to smart contracts. First, wrapp
28
28
regular Python code. Second, a `ChainFacade` class which acts as the network gateway. It will build and sign a
29
29
transaction if state needs to be persisted or use other means for read-only (free) executions.
30
30
31
-
Lets breakdown the following example which queries the blockchain for the symbol of the Neo token contract and
32
-
will return `NEO` as result.
31
+
Lets breakdown the following example which queries the blockchain for the symbol of the EpicChain token contract and
32
+
will return `EpicChain` as result.
33
33
<aname="symbol-reading-example"></a>
34
34
```py3
35
35
facade = ChainFacade.node_provider_mainnet()
36
-
neo=NeoToken()
36
+
epicchain=epicchainToken()
37
37
await facade.test_invoke(neo.symbol())
38
38
```
39
39
Line `1` creates a facade for communicating with the MainNet. While it can be configured to perform automatic
40
40
transaction signing when persisting state, for now it is only important to know that this configured the facade to talk
41
41
to a MainNet RPC node internally.
42
42
43
-
Line `2` instantiates our first wrapper. The `NeoToken` class wraps around the native [NeoToken](https://github.com/neo-project/neo/blob/77ee2cc5b6ea371efdf3be506b173c6304b0fc01/src/Neo/SmartContract/Native/NeoToken.cs#L31)
44
-
smart contract (built-in to the chain) and gives a convenient way of calling the public functions of the smart contract.
45
-
46
-
Line `3` is where the interesting parts happen. The call to `neo.symbol()` does not actually return "NEO", instead it
47
-
builds a sequence of NEO Virtual Machine instructions that the network understands. These instructions need to be sent
43
+
Line `2` is where the interesting parts happen. The call to `neo.symbol()` does not actually return "EpicChain", instead it
44
+
builds a sequence of EpicChain Virtual Machine instructions that the network understands. These instructions need to be sent
48
45
to the network, which is where the `facade` comes in to play. The `facade` has two ways of sending the instructions
49
46
50
47
1.`test_invoke()` - Use for read-only calls. Does not cost GAS.
@@ -64,20 +61,18 @@ choice. For now let's first get a greater understanding of the various wrappers
64
61
65
62
## Contract wrappers
66
63
The smart contract wrappers are a key component in simplifying smart contract interaction. Like the facade they live in
67
-
the `neo3.api.wrappers` module. The NEO blockchain has a few native contracts build into the chain such as the NEO and
68
-
GAS tokens, but also contracts providing information regarding the chain configuration like the
For these kind of contracts specialised wrappers exist like `NeoToken`, `GasToken`, `PolicyContract` and `RoleContract`.
64
+
the `neo3.api.wrappers` module. The EpicChain blockchain has a few native contracts build into the chain such as the EpicChain and
65
+
EpicPulse tokens, but also contracts providing information regarding the chain configuration like thekind of contracts specialised wrappers exist like `EpicChain`, `EpicPulse`, `PolicyContract` and `RoleContract`.
71
66
72
67
### Types of smart contracts
73
68
Technically speaking there are no types of smart contracts. However, they can implement standards that give
74
-
them compartalisable behaviour. For example implementing [NEP-11](https://github.com/neo-project/proposals/blob/master/nep-11.mediawiki)
75
-
gives NFT like behaviour, [NEP-17](https://github.com/neo-project/proposals/blob/master/nep-17.mediawiki) gives
76
-
fungible token behaviour. NEO and GAS are examples of NEP-17 tokens, but there are many more NEP-17 tokens in the system.
77
-
To easily use these contracts there are more generic wrappers available such as `NEP17Contract`, `NEP11DivisibleContract` and
69
+
them compartalisable behaviour. For example implementing [XEP-11](https://github.com/neo-project/proposals/blob/master/nep-11.mediawiki)
70
+
gives NFT like behaviour, [XEP-17](https://github.com/neo-project/proposals/blob/master/nep-17.mediawiki) gives
71
+
fungible token behaviour. EpicChain and GAS are examples of NEP-17 tokens, but there are many more NEP-17 tokens in the system.
72
+
To easily use these contracts there are more generic wrappers available such as `XEP17Contract`, `NEP11DivisibleContract` and
78
73
`NEP11NonDivisibleContract`.
79
74
80
-
All they require is the contract hash and you're ready to call them like NEO or GAS. For example wrapping the
75
+
All they require is the contract hash and you're ready to call them like EpicChain or EpicPulse. For example wrapping the
81
76
[TOTHEMOON](https://dora.coz.io/contract/neo3/mainnet/0x56199aa066633745de4d603e6477881455c08243) token is done as follows
82
77
83
78
```py3 linenums="0"
@@ -105,7 +100,7 @@ The diagram below shows the structure
105
100
* White are building blocks and not intended to be used on their own. They are shown to make the picture complete.
106
101
107
102
## Modifying chain state
108
-
This section shows what it takes to modify chain state, specifically we'll show how to transfer a NEP-17 token (NEO) and
103
+
This section shows what it takes to modify chain state, specifically we'll show how to transfer a NEP-17 token (EpicChain) and
109
104
break down the steps and options.
110
105
111
106
We've [previously](#symbol-reading-example) seen how to query the `symbol` of a contract by using the `test_invoke()`
In order to transfer tokens we need to have an account with funds to transfer them from. Secondly, all transactions are
156
-
paid for with `GAS`. So while this example transfers `NEO`, the account must also hold a bit of `GAS` to pay for the
157
-
fees. For the aforementioned reasons we assume you already have a [NEP-6](https://github.com/neo-project/proposals/blob/master/nep-6.mediawiki)
151
+
paid for with `GAS`. So while this example transfers `EpicChain`, the account must also hold a bit of `EpicPulse` to pay for the
152
+
fees. For the aforementioned reasons we assume you already have a [XEP-6](https://github.com/neo-project/proposals/blob/master/nep-6.mediawiki)
158
153
wallet that we'll load from disk.
159
154
160
155
!!! tip
@@ -183,7 +178,7 @@ It states that `account` agrees with the modification that the transaction `scri
183
178
will verify the validity of the signature before performing the transfer.
184
179
185
180
The `Signer` will have a scope of `CALLED_BY_ENTRY` by default. This means that the signature is only valid inside the
186
-
first contract called. In this case that will be the `NeoToken` contract. This scope can be checked by the
181
+
first contract called. In this case that will be the `EpicChain` contract. This scope can be checked by the
187
182
`CheckWitness` function inside smart contracts to avoid abuse. There are many scenarios where one contract may need to
188
183
call one or more other contracts. For such cases the signer can be configured with other scope options and rules. This
189
184
however is beyond the scope of this example and can be learned more about [in this excellent article](https://neospcc.medium.com/thou-shalt-check-their-witnesses-485d2bf8375d)
0 commit comments