Reorg structure (#1148)

* adjust structure

* update

* fix links

* fix links

* fix links

* Update prerequisites.md

* update English

* reorg

* updated

* fix links

fix links

* Update index.md

* update rpc and sc (#1142)

* update rpc api

* fix

* update sc api

* update sc framework

* update fee

* some updates in develop

* update opcode fee

Co-authored-by: Celia18305 <[email protected]>

* updated

* update api

* Update to the latest. (#1143)

* add oracle

* some updates (#1144)

* update rpc api

* fix

* update sc api

* update sc framework

* update fee

* some updates in develop

* update opcode fee

* update intro

* update nep5

* update sdk

* updated English SDK

* follow up

Co-authored-by: Celia18305 <[email protected]>
Co-authored-by: Celia18305 <[email protected]>

* add oralce

* update toc

* update

* update scapi (#1145)

* update rpc api

* fix

* update sc api

* update sc framework

* update fee

* some updates in develop

* update opcode fee

* update intro

* update nep5

* update sdk

* updated English SDK

* follow up

* update scapi

* update method descriptors

* updated

Co-authored-by: Celia18305 <[email protected]>
Co-authored-by: Celia18305 <[email protected]>

* update setup

* update index

Co-authored-by: cn1010 <[email protected]>
Co-authored-by: Owen Zhang <[email protected]>

config.json

@@ -16,22 +16,6 @@
       "webRoot": "wwwroot",
       "git": "https://github.com/neo-project/docs/blob/new-release-neo3/docs/en-us/"
     },
-    {
-      "origin": "tutorial\\zh-cn",
-      "template": "template",
-      "destination": "..\\docs\\wwwroot\\v3\\tutorial\\zh-cn",
-      "catalog": "tutorial\\zh-cn\\toc.yml",
-      "webRoot": "wwwroot",
-      "git": "https://github.com/neo-project/docs/blob/new-release-neo3/tutorial/zh-cn/"
-    },
-    {
-      "origin": "tutorial\\en-us",
-      "template": "template",
-      "destination": "..\\docs\\wwwroot\\v3\\tutorial\\en-us",
-      "catalog": "tutorial\\en-us\\toc.yml",
-      "webRoot": "wwwroot",
-      "git": "https://github.com/neo-project/docs/blob/new-release-neo3/tutorial/en-us/"
-    },
     {
       "origin": "faq\\zh-cn",
       "template": "template",

docs/en-us/advanced/oracle.md

@@ -0,0 +1,84 @@
+# Oracles
+
+Oracle solutions enable the Blockchain to obtain external data from the outside network. As a gateway for smart contracts to communicate with the outside network, Oracles open a window to the outside world for the blockchain. For data requested outside the Blockchain, Oracles guarantee the truthfulness or reliability of the results through multi-party verification, and store the results in the form of blocks on the chain for the smart contract to get access to this data.
+
+## Neo Oracles
+
+Neo provides a built-in Oracle service with native contracts, which can be invoked by other contracts. In order to get the data outside the blockchain, the contract first needs to construct an Oracle request transaction, and after it is deployed on the chain, the Neo Oracle service can be invoked.
+
+Oracle nodes elected by the committee and other nodes in the network assist in the operation of transactions. When the Oracle transaction is broadcast, each node stores the currently unverified transaction as a known hash in its memory pool and pass it to other nodes. Through this process, the Oracle node of the Oracle transaction uses the URL and filters to complete all included requests. Then, by appending the result to the TransactionAttribute part of the Oracle transaction, these nodes reach a consensus on the response data that returned.
+
+Once enough signatures are collected, the Oracle transaction is regarded as verified and stored in a block by the consensus node, which can be accessed by the contract after the block is on the chain.
+
+Oracle nodes charge a certain amount of transaction fees. You can pay GAS for Oracle transactions on Neo blockchain.
+
+![](assets/oracle.png)
+
+## Oracle requests
+
+| Field            | Bytes     | Description                                                  |
+| ---------------- | --------- | ------------------------------------------------------------ |
+| Url              | string    | Url of the request                                           |
+| Filter           | string    | Filter, used to filter useless data                          |
+| CallbackContract | 20 bytes  | Callback the contract                                        |
+| CallbackMethod   | string    | The callback method name                                     |
+| UserData         | var bytes | Extra data provided by the user                              |
+| GasForResponse   | long      | The fee for getting the response, which is set by the contract that calls the Oracle service |
+
+### GasForResponse
+
+The fee for getting the response. `GasForResponse` should not be less than 0.1 GAS, otherwise the Oracle request cannot be initiated.
+
+### Filter
+
+Filters are used to filter out useful information in the results returned from the data source, where the Filter field is a `JSONPath` expression. For more information, click [Here](https://github.com/json-path/JsonPath).
+
+## Oracle response
+
+When constructing the `Response` transaction, the `finish` method of the Oracle contract is called to execute the callback function `CallbackMethod`. The callback function is defined in the request transaction contract. The callback function usually requires the following fields:
+
+| Field    | Bytes     | Description                     |
+| -------- | --------- | ------------------------------- |
+| Url      | string    | Url of the request              |
+| UserData | var bytes | Extra data provided by the user |
+| Code     | byte      | Oracle response code            |
+| Result   | var bytes | Response result                 |
+
+### Code
+The Code field defines the execution result of response transactions. It includes the following five types:
+
+| Value  | Response    | Description                        | Type   |
+| ------ | ----------- | ---------------------------------- | ------ |
+| `0x00` | `Success`   | Executed successfully.             | `byte` |
+| `0x01` | `NotFound`  | The requested message is not found | `byte` |
+| `0x12` | `Timeout`   | Execution timeout                  | `byte` |
+| `0x14` | `Forbidden` | No execution permission            | `byte` |
+| `0xff` | `Error`     | Execution error                    | `byte` |
+
+## An Oracle contract example
+
+```C#
+    public class OracleDemo : SmartContract
+    {
+        public static void DoRequest()
+        {
+            string url = "http://127.0.0.1:8080/test";
+            string filter = "$.value";  // JSONPath, { "value": "hello world" }
+            string callback = "callback";
+            object userdata = "userdata"; // arbitrary type
+            long gasForResponse = 10000000; // minimum fee 
+
+            Oracle.Request(url, filter, callback, userdata, gasForResponse);
+        }
+
+        public static void Callback(string url, string userdata, int code, string result)
+        {
+            object ret = Json.Deserialize(result); // [ "hello world" ]
+            object[] arr = (object[])ret;
+            string value = (string)arr[0];
+
+            Runtime.Log("userdata: " + userdata);
+            Runtime.Log("response value: " + value);
+        }
+    }
+```

docs/en-us/tooldev/concept/charging_model.md → docs/en-us/basic/concept/charging_model.md

@@ -11,4 +11,4 @@ Network fee is the fee to pack transactions into a block. Users can define the a
 ### System Fee
 System fees are the cost of resources consumed by the transaction execution in NeoVM. The total fee depends on the number and type of instructions executed in the smart contract script. 
 
-Additionally, when running a smart contract, system calls or instructions executed by NeoVM also incur system fees. For details, refer to [Fees](../../sc/fees.md).
+Additionally, when running a smart contract, system calls or instructions executed by NeoVM also incur system fees. For details, refer to [Fees](../../reference/fees.md).

docs/en-us/tooldev/concept/endian.md → docs/en-us/basic/concept/endian.md

@@ -16,10 +16,9 @@ Let's look at a standard wallet address and corresponding scripthash strings in
   - Big endian：0x946d6caa602a2b85fbeb7cf05335b2c3b124f1e4
   - Little endian：e4f124b1c3b23553f07cebfb852b2a60aa6c6d94
 
-To convert between the wallet address and scripthash, or between big endian and little endian byte order, use one of the following:
+To convert between the wallet address and scripthash, or between big endian and little endian byte order, use the following:
 
 - [DataTransformationTools](https://peterlinx.github.io/DataTransformationTools/)
-- Neo SDK (See [Data Conversion](../sdk/conversion.md))
 
 ### The contract scripthash
 When a contract has been deployed a scripthash is generated as a unified identifier of the contract. The contract scripthash can be converted into the standard 20-byte address for receiving assets from transfer transactions. In that case the contract scripthash is used in big endian format. For example:

docs/en-us/tooldev/transaction/transaction.md → docs/en-us/basic/concept/transaction.md

@@ -53,15 +53,15 @@ Scopes defines the effective range of the signature, including these types:
 
 The system fee is calculated by opcodes to be executed by the Neo virtual machine. The 10 GAS free system fee is canceled in Neo3. The total fee is subject to the quantity and type of instructions in the contract script. The calculation formula is as follows:
 
-![](../../../zh-cn/tooldev/images/transaction/system_fee.png)
+![](../../../zh-cn/basic/images/transaction/system_fee.png)
 
-where *OpcodeSet* is opcode set, *OpcodePrice<sub>i</sub>* is the cost of opcode i, *n<sub>i</sub>* is the execution times of instruction i in the contract script. For each opcode fee refer to [Fees for Instructions](../../sc/fees.md#fees-for-instructions).
+where *OpcodeSet* is opcode set, *OpcodePrice<sub>i</sub>* is the cost of opcode i, *n<sub>i</sub>* is the execution times of instruction i in the contract script. For each opcode fee refer to [Fees for Instructions](../../reference/fees.md#fees-for-instructions).
 
 ### netfee
 
 The network fee is charged when the user submits a transactions to Neo blockchain as a reward for consensus nodes generating blocks. There is a  base fee for each transaction. The transaction is only executed if the fee paid by the user is greater than or equal to the base fee; otherwise, the transaction will be treated as invalid. The calculation formula is as follows:
 
-![network fee](../../../zh-cn/tooldev/images/transaction/network_fee.png)
+![network fee](../../../zh-cn/basic/images/transaction/network_fee.png)
 
 where *VerificationCost* is the fee for instructions executed by NeoVM to verify transaction signatures, *tx.Length* is the transaction data byte length, and *FeePerByte* is transaction fee per byte, currently 0.00001 GAS.
 
@@ -97,7 +97,7 @@ By repeating this step, the invocation script can push multiple signatures for t
 
 #### VerificationScript
 
-Verification script, commonly known as address script, includes normal address script and multi-signature address script. The address script can be directly obtained from the wallet account. For information about the construction refer to [Wallets](../wallets.md#address).
+Verification script, commonly known as address script, includes normal address script and multi-signature address script. The address script can be directly obtained from the wallet account. For information about the construction refer to [Wallets](wallets.md#address).
 
 It can also be used as a custom authentication contract script.
 

docs/en-us/tooldev/wallets.md → docs/en-us/basic/concept/wallets.md

@@ -8,7 +8,7 @@ You can redesign and modify Neo wallets following your own thoughts, but the bel
 
 In Neo, the account is the smart contract and the address represents a contract script. The below flow diagram shows how to derive the public key from the private key and then to the address:
 
-![](images\wallets\privatekey-2-publickey-address.png)
+![](../images/wallets/privatekey-2-publickey-address.png)
 
 ### Private Key
 
@@ -24,7 +24,7 @@ There are two main encoding formats for private keys in Neo:
 
    The wif format is to add prefix `0x80` and suffix `0x01` in the original 32-byte data, and get the string after Base58Check encoding.
 
-![](images\wallets\wif_format.png)
+![](../images/wallets\wif_format.png)
 
  Example: 
 
@@ -70,7 +70,7 @@ Address is a string of numbers and letters after a series of transformations of
     0x0C + 0x21 + Public Key(Compressed 33 bytes) + 0x0B + 0x41 + 0x0a906ad4
     ```
 
-    ![](images\wallets\account_address_script_checksign.png)
+    ![](..\images\wallets\account_address_script_checksign.png)
 
 2. Calculate script hash of the contract (20 bytes, make once SHA256 and RIPEMD160 of the script). 
 
@@ -231,7 +231,7 @@ An NEP6 wallet uses scrypt algorithm as the core method of wallet encryption and
 
 #### Encryption steps
 
-![](images\wallets\nep2key.png)
+![](..\images\wallets\nep2key.png)
 
 1. The address is derived from the public key, and the address hash is the first four bytes of `SHA256(SHA256(Address))`
 
@@ -358,7 +358,7 @@ Example:
 
 The full-node wallet is a complete backup of blockchain data, which saves all the onchain data and participates in p2p network, therefore it needs a large storage space.
 
-Neo-CLI and Neo-GUI are all full-node wallet. For more information refer to [Neo node](../node/introduction.md).
+Neo-CLI and Neo-GUI are all full-node wallet. For more information refer to [Neo node](../../node/introduction.md).
 
 ### SPV wallet
 

docs/en-us/tooldev/consensus/consensus_algorithm.md → docs/en-us/basic/consensus/consensus_algorithm.md

@@ -1,7 +1,5 @@
 # dBFT 2.0 Algorithm
 
-Neo proposes dBFT (delegated Byzantine Fault Tolerance) consensus algorithm based on the PBFT (Practical Byzantine Fault Tolerance) algorithm. The dBFT algorithm determines the next-consensus-round validators based on real-time blockchain voting, which effectively enhances the efficiency of the algorithm, and saves block time and transaction confirmation time. dBFT2.0, as an upgraded version, was released in March, 2019, which improves robustness and safety by introducing the 3-stage consensus mechanism as well as a recovery mechanism.
-
 ## Terms
 
 | **Term**  | **Definition**                                               |

docs/en-us/basic/technology/dbft.md → docs/en-us/basic/consensus/dbft.md

@@ -34,7 +34,7 @@ A new block will be generated with each round of consensus, with at least N −
 
 ###  General Procedures 
 
-![](../../tooldev/images/consensus/1.png)
+![](../../basic/images/consensus/1.png)
 
 A round of consensus consists of 4 steps, as shown in the Figure above.
 
@@ -72,11 +72,3 @@ Hence the success of block generation means:
 - The rest of the validators are insufficient to produce another different block.
 
 Therefore, the finality of the new block can be guaranteed at a given height.
-
-## Further Reading
-
-[Consensus Algorithm](../../tooldev/consensus/consensus_algorithm.md)
-
-[Consensus Protocol](../../tooldev/consensus/consensus_protocol.md)
-
-[Voting](../../tooldev/consensus/vote_validator.md)

docs/en-us/basic/technology/neovm.md → docs/en-us/basic/neovm.md

@@ -14,7 +14,7 @@ In addition, NeoVM is highly decoupled from the upper-level code and customizabl
 
 The NeoVM architecture is mainly composed of the execution engine, stack, and interoperation service layer. 
 
-![](../../assets/neovm.png)
+![](../assets/neovm.png)
 
 #### ExecutionEngine