Welcome to the EOS.IO source code repository! EOS.IO software enables developers to create and deploy
high-performance, horizontally scalable, blockchain infrastructure upon which decentralized applications
can be built.
can be built.
This code is currently alpha-quality and under rapid development. That said,
there is plenty early experimenters can do including, running a private multi-node test network and
develop applications (smart contracts).
develop applications (smart contracts).
# Resources
1.[EOS.IO Website](https://eos.io)
...
...
@@ -58,7 +58,7 @@ For Ubuntu 16.10 and MacOS Sierra, there is an automated build script that can i
It is called build.sh with following inputs.
- architecture [ubuntu|darwin]
- optional mode [full|build]
- optional mode [full|build]
The second optional input can be full or build where full implies that it installs dependencies and builds eos. If you omit this input then build script always installs dependencies and then builds eos.
...
...
@@ -68,13 +68,13 @@ The second optional input can be full or build where full implies that it instal
Clone EOS repository recursively as below and run build.sh located in root `eos` folder.
Now you can proceed to the next step - [Creating and launching a single-node testnet](#singlenode)
...
...
@@ -99,10 +99,10 @@ cd eos
Now you can proceed to the next step - [Creating and launching a single-node testnet](#singlenode)
<aname="runanode"></a>
## Building EOS and running a node
## Building EOS and running a node
<aname="getcode"></a>
### Getting the code
### Getting the code
To download all of the code, download EOS source code and a recursion or two of submodules. The easiest way to get all of this is to do a recursive clone:
The *WASM_LLVM_CONFIG* environment variable is used to find our recently built WASM compiler.
This is needed to compile the example contracts inside `eos/contracts` folder and their respective tests.
...
...
@@ -146,7 +146,7 @@ EOS comes with a number of programs you can find in `~/eos/build/programs`. They
* launcher - application for nodes network composing and deployment; [more on launcher](https://github.com/EOSIO/eos/blob/master/testnet.md)
<aname="singlenode"></a>
### Creating and launching a single-node testnet
### Creating and launching a single-node testnet
After successfully building the project, the `eosd` binary should be present in the `build/programs/eosd` directory. Go ahead and run `eosd` -- it will probably exit with an error, but if not, close it immediately with <kbd>Ctrl-C</kbd>. Note that `eosd` created a directory named `data-dir` containing the default configuration (`config.ini`) and some other internals. This default data storage path can be overridden by passing `--data-dir /path/to/data` to `eosd`.
...
...
@@ -203,7 +203,7 @@ When running `eosd` you should get log messages similar to below. It means the b
<aname="smartcontracts"></a>
## Example "Currency" Contract Walkthrough
EOS comes with example contracts that can be uploaded and run for testing purposes. Next we demonstrate how to upload and interact with the sample contract "currency".
EOS comes with example contracts that can be uploaded and run for testing purposes. Next we demonstrate how to upload and interact with the sample contract "currency".
<aname="smartcontractexample"></a>
### Example smart contracts
...
...
@@ -216,7 +216,7 @@ cd ~/eos/build/programs/eosd/
```
<aname="walletimport"></a>
### Setting up a wallet and importing account key
### Setting up a wallet and importing account key
As you've previously added `plugin = eosio::wallet_api_plugin` into `config.ini`, EOS wallet will be running as a part of `eosd` process. Every contract requires an associated account, so first, create a wallet.
...
...
@@ -225,7 +225,7 @@ cd ~/eos/build/programs/eosc/
./eosc wallet create # Outputs a password that you need to save to be able to lock/unlock the wallet
```
For the purpose of this walkthrough, import the private key of the `inita` account, a test account included within genesis.json, so that you're able to issue API commands under authority of an existing account. The private key referenced below is found within your `config.ini` and is provided to you for testing purposes.
For the purpose of this walkthrough, import the private key of the `inita` account, a test account included within genesis.json, so that you're able to issue API commands under authority of an existing account. The private key referenced below is found within your `config.ini` and is provided to you for testing purposes.
@@ -255,7 +255,7 @@ Save the values for future reference.
Run the `create` command where `inita` is the account authorizing the creation of the `currency` account and `PUBLIC_KEY_1` and `PUBLIC_KEY_2` are the values generated by the `create key` command
@@ -328,11 +328,11 @@ Next verify the currency contract has the proper initial balance:
```
<aname="pushamessage"></a>
### Transfering funds with the sample "currency" contract
### Transfering funds with the sample "currency" contract
Anyone can send any message to any contract at any time, but the contracts may reject messages which are not given necessary permission. Messages are not
sent "from" anyone, they are sent "with permission of" one or more accounts and permission levels. The following commands shows a "transfer" message being
sent to the "currency" contract.
sent to the "currency" contract.
The content of the message is `'{"from":"currency","to":"inita","amount":50}'`. In this case we are asking the currency contract to transfer funds from itself to
someone else. This requires the permission of the currency contract.
...
...
@@ -356,14 +356,14 @@ As a confirmation of a successfully submitted transaction you will receive json
<aname="readingcontract"></a>
### Reading sample "currency" contract balance
So now check the state of both of the accounts involved in the previous transaction.
So now check the state of both of the accounts involved in the previous transaction.
```bash
./eosc get table inita currency account
{
"rows": [{
"account": "account",
"balance": 50
"balance": 50
}
],
"more": false
...
...
@@ -379,10 +379,10 @@ So now check the state of both of the accounts involved in the previous transact
}
```
As expected, the receiving account **inita** now has a balance of **50** tokens, and the sending account now has **50** less tokens than its initial supply.
As expected, the receiving account **inita** now has a balance of **50** tokens, and the sending account now has **50** less tokens than its initial supply.
<aname="localtestnet"></a>
## Running multi-node local testnet
## Running multi-node local testnet
To run a local testnet you can use a `launcher` application provided in `~/eos/build/programs/launcher` folder.
...
...
@@ -399,9 +399,6 @@ This command will generate 2 data folders for each instance of the node: `tn_dat
wlog("caught an exception getting block id for ${pl}",("pl",peer_lib));
on_fork=true;
}
if(on_fork){
elog("Peer chain is forked");
c->enqueue(go_away_message(forked));
return;
}
}
if(c->sent_handshake_count==0){
c->send_handshake();
}
}
c->last_handshake=msg;
sync_master->reset_lib_num();
c->syncing=false;
//--------------------------------
// sync need checkz;
//
// 0. my head block id == peer head id means we are all caugnt up block wize
// 1. my lib < peer lib - start sync locally
// 2. my lib > peer lib - send an last_irr_catch_up notice if not the first generation
//
// 3 my head block num <= peer head block num - update sync state and send a catchup request
// 4 my head block num > peer block num ssend a notice catchup if this is not the first generation
//
//-----------------------------
uint32_thead=cc.head_block_num();
block_id_typehead_id=cc.head_block_id();
if(sync_master->syncing()){
fc_dlog(logger,"sync check state -1");
sync_master->start_sync(c,peer_lib);
return;
}
if(head_id==msg.head_id){
fc_dlog(logger,"sync check state 0");
notice_messagenote;
note.known_blocks.mode=none;
note.known_trx.mode=catch_up;
note.known_trx.pending=local_txns.size();
c->enqueue(note);
return;
}
if(lib_num<peer_lib){
fc_dlog(logger,"sync check state 1");
sync_master->start_sync(c,peer_lib);
return;
}
if(lib_num>peer_lib){
fc_dlog(logger,"sync check state 2");
if(msg.generation>1){
notice_messagenote;
note.known_trx.mode=none;
note.known_blocks.mode=last_irr_catch_up;
note.known_blocks.pending=lib_num;
c->enqueue(note);
}
c->syncing=true;
return;
}
if(head<=msg.head_num){
fc_dlog(logger,"sync check state 3");
request_messagereq;
req.req_trx.mode=none;
req.req_blocks.mode=catch_up;
req.req_blocks.pending=lib_num;
c->enqueue(req);
return;
}
else{
fc_dlog(logger,"sync check state 4");
if(msg.generation>1){
notice_messagenote;
note.known_trx.mode=none;
note.known_blocks.mode=catch_up;
note.known_blocks.pending=head-lib_num;
c->enqueue(note);
}
c->syncing=true;
return;
}
elog("sync check failed to resolbe status");
return;
#if 0
if( peer_lib > head || sync_master->syncing() ) {
sync_master->start_sync( c, peer_lib );
}
...
...
@@ -1543,23 +1622,26 @@ namespace eosio {
fc_dlog(logger, "msg.head_id = ${m} our head = ${h}",("m",msg.head_id)("h",head_id));
notice_message note;
note.known_blocks.mode=id_list_modes::none;
note.known_blocks.mode = none;
fc_dlog(logger, "msg head = ${mh} msg lib = ${ml} my head = ${h} my lib = ${l}",("mh",msg.head_num)("ml",msg.last_irreversible_block_num)("h",head)("l",lib_num));
fc_dlog(logger,"sending ${m} notice to ${n} about ${t} txns and ${b} blocks",("m",modes_str(note.known_blocks.mode))("n",c->peer_name())("t",note.known_trx.pending)("b",note.known_blocks.pending));
c->enqueue(note);
if (msg.generation > 1 && note.known_blocks.mode == catch_up) {
fc_dlog(logger, "sending ${m} notice to ${n} about ${t} txns and ${b} blocks",("m",modes_str(note.known_blocks.mode))("n",c->peer_name())("t",note.known_trx.pending)("b",note.known_blocks.pending));
