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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
**We will be using 3 virtual machines as 3 Ethereum node. We used 'Ubuntu Server 14.04 LTS trusty', and 'Ubuntu 15.10 wily' for this experiment. Root Ethereum node will be referred as 'root node', client nodes will be referred as 'client node A' & 'client node B' respectively. On root node port 30303 must be accessible from outside.**
## Installation
Below are the installation instructions for the latest versions of Ubuntu. This step must be executed and Ethereum go client 'geth' must be installed on every node.
#### Building for Ubuntu 14.04 & above, 64 bit
#### Install dependencies & geth client
Before you can build the source, you need several tools and dependencies for the application to get started.
First, update your repositories. Not all packages are provided in the main Ubuntu repository, those you'll get from the Ethereum PPA and the LLVM archive.
*NOTE: 14.04 users, you'll need the latest version of cmake. For this, use:*
Darwin 0mkars-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
```
Use the following command to install geth:
3 physical machines were used as 3 Ethereum nodes for this experiment. Ethereum node on **Raspberrypi** was setup to act as bootnode. Other two Ethereum nodes were connected to the bootnode by setting `--bootnode` parameter.
```
sudo apt-get install ethereum
```
## Installation
Please follow standart setup process or use prebuilt binaries from https://geth.ethereum.org/downloads/
*A genesis block is the first block of a block chain. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1. The genesis block is almost always hardcoded into the software. It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.*
For detailed explanation of genesis file component [see here](#file-genesis-md).
Check if root node is accessible from external network. We will execute following commands on some machine outside from the **'root node's' network.**:
telnet 54.239.25.200 30303
sudo nmap -sU -p 30303 54.239.25.200
**Work on root node is complete now.** We will create two client node and connect to our root node.
## Create 'client node A' & 'client node B'
**Now we will prepare our client nodes. Execute following commands on both client nodes.**
We have defined very low mining difficulty *"difficulty": "0x0100"*, this will allow us to generate some Ether very quickly. After some time we will be able to see some balance on our client node.
*A genesis block is the first block of a blockchain. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1. The genesis block is almost always hardcoded into the software. It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.*
**Finally we are ready to transfer some balance.** Let us assume base address of **client node A** is '0x036a03fc47084741f83938296a1c8ef67f6e34fa' and base address of **client node B** is '0xa8ade7feab1ece71446bed25fa0cf6745c19c3d5'.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
*A genesis block is the first block of a block chain. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1. The genesis block is almost always hardcoded into the software. It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.*
For detailed explanation of genesis file component [see here](#file-genesis-md).
Initialize network and start geth console:
0mkara
revised
this gist Jan 24, 2016.
1 changed file
with
1 addition
and
1 deletion.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
**We will be using 3 virtual machines as 3 Ethereum node. We used 'Ubuntu Server 14.04 LTS trusty', and 'Ubuntu 15.10 wily' for this experiment. Root Ethereum node will be referred as 'root node', client nodes will be referred as 'client node A' & 'client node B' respectively. On root node port 30303 must be accessible from outside.**
## Installation
Below are the installation instructions for the latest versions of Ubuntu. This step must be executed and Ethereum go client 'geth' must be installed on every node.
#### Building for Ubuntu 14.04 & above, 64 bit
#### Install dependencies & geth client
Before you can build the source, you need several tools and dependencies for the application to get started.
First, update your repositories. Not all packages are provided in the main Ubuntu repository, those you'll get from the Ethereum PPA and the LLVM archive.
*NOTE: 14.04 users, you'll need the latest version of cmake. For this, use:*
Check if root node is accessible from external network. We will execute following commands on some machine outside from the **'root node's' network.**:
telnet 54.239.25.200 30303
sudo nmap -sU -p 30303 54.239.25.200
**Work on root node is complete now.** We will create two client node and connect to our root node.
## Create 'client node A' & 'client node B'
**Now we will prepare our client nodes. Execute following commands on both client nodes.**
We have defined very low mining difficulty *"difficulty": "0x0100"*, this will allow us to generate some Ether very quickly. After some time we will be able to see some balance on our client node.
**Finally we are ready to transfer some balance.** Let us assume base address of **client node A** is '0x036a03fc47084741f83938296a1c8ef67f6e34fa' and base address of **client node B** is '0xa8ade7feab1ece71446bed25fa0cf6745c19c3d5'.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
> A 256-bit hash which proves, combined with the nonce, that a sufficient amount of computation has been carried out on this block: the Proof-of-Work (PoF).
> The combination of nonce and mixhash must satisfy a mathematical condition described in the Yellowpaper, 4.3.4. Block Header Validity, (44). It allows to verify that the Block has really been cryptographically mined, thus, from this aspect, is valid.
> The value is a reduced representation (using a simple Fowler–Noll–Vo hash function) of the set of values selected from the DAG data file during mining calculation. This selection pick follows the implemented Estah' Hashimoto algorithm, which depends on the given Block header. The applied mixhash is re-determined for each hash operation that a Miner performs while searching for the correct Block nonce (cf. ASIC resistance, high IO). The final Block mixhash is the value leading to the valid Block. The reason why this value is part of the Block descriptor is that it becomes part of the //parentHash// of the next Block. By this, a potential attacker would need correct DAG data files to create illegal Blocks.
***nonce**
> A scalar value equal to the number of transactions sent by the sender.
> A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block.
> The nonce is the cryptographically secure mining proof-of-work that proves beyond reasonable doubt that a particular amount of computation has been expended in the determination of this token value. (Yellowpager, 11.5. Mining Proof-of-Work).
> The final nonce value is the result of the the mining process iteration, in which the algorithm was able to discover a nonce value that satisfies the Mining Target. The Mining Target is a cryptographically described condition that strongly depends on the applied . Just by using the nonce Proof-of-Work, the validity of a Block can verified very quickly.
***difficulty**
> A scalar value corresponding to the difficulty level applied during the nonce discovering of this block. It defines the Mining Target, which can be calculated from the previous block’s difficulty level and the timestamp. The higher the difficulty, the statistically more calculations a Miner must perform to discover a valid block. This value is used to control the Block generation time of a Blockchain, keeping the Block generation frequency within a target range. On the test network, we keep this value low to avoid waiting during tests since the discovery of a valid Block is required to execute a transaction on the Blockchain.
***alloc**
> Allows to define a list of pre-filled wallets. That's a Ethereum specific functionality to handle the "Ether pre-sale" period. Since we can mine local Ether quickly, we don't use this option.
***coinbase**
> The 160-bit address to which all rewards (in Ether) collected from the successful mining of this block have been transferred. They are a sum of the mining eward itself and the Contract transaction execution refunds. Often named "beneficiary" in the specifications, sometimes "etherbase" in the online documentation. This can be anything in the Genesis Block since the value is set by the setting of the Miner when a new Block is created.
***timestamp**
> A scalar value equal to the reasonable output of Unix’ time() function at this block inception.
> This mechanism enforces a homeostasis in terms of the time between blocks. A smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required to find the next valid block. If the period is too large, the difficulty, and expected time to the next block, is reduced.
> The timestamp also allows to verify the order of block within the chain (Yellowpaper, 4.3.4. (43)).
> Note: Homeostasis is the property of a system in which variables are regulated so that internal conditions remain stable and relatively constant.
***parentHash**
> The Keccak 256-bit hash of the entire parent block’s header (including its nonce and mixhash). Pointer to the parent block, thus effectively building the chain of blocks. In the case of the Genesis block, and only in this case, it's 0.
***extraData**
> An optional free, but max. 32 byte long space to conserve smart things for ethernity on the Blockchain.
***gasLimit**
> A scalar value equal to the current chain-wide limit of Gas expenditure per block. High in our case to avoid being limited by this threshold during tests. Note: this does not indicate that we should not pay attention to the Gas consumption of our Contracts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters