Zentanetwork

Status
This project is under active development, there may be breaking changes.
Zentanetwork
Zentanetwork is a forkless PoS consensus for communication and data storage. Zentachain's native token is called Zentachain CHAIN. The consensus used by Zentanetwork is the Proof of stake (PoS) algorithm. Zentalk users can earn CHAIN tokens by supporting the Zentanetwork. To become a validator, users need to have some CHAIN, and lock (Bonding) up the tokens. Thus, users will both strengthen the Zentanetwork and will be rewarded at the rate of  CHAIN they regularly stake.
Rust
Rust is a programming language designed for security, speed, and concurrency. Its structure lets you create programs that have the power and control of a low-level language, but with the powerful abstractions of a high-level language. Rust performs most of its security checks and memory management decisions at compile-time, so it does not affect the runtime performance of your program. This makes Rust useful for a number of use cases for which other languages are not suitable: Programs with predictable memory and timing, embedding in other languages, and writing low-level code such as device drivers, operating systems, blockchain, or even networks. The network is built with the Substrate framework.
Cargo
Cargo is Rust’s build system and package manager. Most use this tool to manage their Rust projects. Cargo handles a lot of tasks, such as building your code, downloading the libraries your code depends on, and building those libraries. When you write more complex Rust programs, you will add dependencies, and when you start a project with Cargo, adding dependencies will be much easier.
Substrate
Substrate framework can be defined as an open-source community, a modular software development framework, and a developer platform. The Substrate framework provides modular development of fast, secure, and forkless blockchains using Substrate palettes.
Starting with Rust
1.0 Installation Rust on Windows
rustup.rs - The Rust toolchain installer
Please follow the instructions to download rustup-init.exe
1.1 Installing Rust on macOS
Open terminal and type:
1
$ curl https://sh.rustup.rs -sSf | sh
Copied!
Wasm Environment
1
$ ./scripts/init.sh
Copied!
🎉 Great Rust is now installed  🎉
Fast Commands
1.2 Updating Rust
1
$ rustup update
Copied!
1.3 Uninstalling Rust
1
$ rustup self uninstall
Copied!
1.4 Troubleshooting on Rust
1
$ rustc --version
Copied!
1.5 Downgrade Nightly Version
1
$ rustup install nightly-YYYY-MM-DD
Copied!
1.6 Overwrite Version specific project
1
$ rustup override set nightly-YYYY-MM-DD
Copied!
 1.7 To install a specific Rust version use:
1
$ rustup toolchain install 1.30.0 (Example)
Copied!
1.8 Rust Version Managing
Introduction - The rustup book
1.9 Change between the version in the directory:
If you'd like to have a different default per-directory, that's easy too! If you run this inside of a project:
1
$ rustup override set nightly 
Copied!
Or, if you'd like to target a different version of Rust:
1
$ rustup override set 1.30.0
Copied!
Apple M1 - Compile Error Handling
If you use a Mac with an M1 chip you will get an error. This will help you to fix this error.
1) Open the Cargo.toml
2) Add some codes on top of the file and save it:
[patch.crates-io]
librocksdb-sys = {git = "https://github.com/hdevalence/rust-rocksdb", branch = "master"}
3)  Find & Open Cargo.lock search for the libc package and replace it with:
1
[[package]]
2
name = "libc"
3
version = "0.2.81"
4
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1482821306169ec4d07f6aca392a4681f66c75c9918aa49641a2595db64053cb"
Copied!
4) Now let's update two libraries with the command line:
 cargo update -p ring fs-swap
You can now re-compile the code and continue the documentation on your M1 MacBook.
Error: E0463 Can't find std.
Be sure you have add nighlty run the command:
1
rustup target add wasm32-unknown-unknown --toolchain nightly
2
​
3
OR
4
​
5
rustup target add wasm32-unknown-unknown --toolchain nightly-2021-02-10
Copied!
Cargo
1.0 Cargo version
1
$ cargo --version
Copied!
Cargo Building & Running
1
$ cargo build
Copied!
Cargo check (Quickly checks your code to make sure it compiles)
1
$ cargo check
Copied!
1.1 Building for Release
When your project is finally ready for release, you can use cargo build --release to compile it with optimizations. This command will create an executable in target/release instead of target/debug. The optimizations make your Rust code run faster, but turning them on lengthens the time it takes for your program to compile the code. If you’re benchmarking your code’s running time, be sure to run cargo build --release and benchmark with the executable in target/release
Introduction - The Cargo Book
Start with Substrate Framework
1.0 Start Substrate on Windows
Getting Started on Windows · Substrate Developer Hub
1.1 Start Substrate on macOS
Installation · Substrate Developer Hub
Makefile
Setup / Install Choco
Chocolatey Software Docs | Setup / Install
Chocolatey Software
To install GNU make, run the following command from the command line or from PowerShell:
1
$ choco install make
Copied!
Subkey
A Subkey is a tool that generates keys specifically designed to be used with Substrate. This may take up to 15 minutes.
1.0 Install Subkey
1
$ cargo install --force subkey --git https://github.com/paritytech/substrate --version 2.0.0
Copied!
1.1 Generate sr25519 Key (Disconnect Internet!) 
1
$ subkey generate --scheme sr25519
Copied!
1.2 Generate ed25519 Key (Disconnect Internet!)
1
$ subkey inspect --scheme ed25519 "--Seed--Phrase--"
Copied!
1.3 Generate a Password Protected Key-Pairs
1
add command --password "enter-password-here"
Copied!
1.4 For more security, use (supports 12, 15, 18, 21, and 24)
1
add command --words 24 
Copied!
1.5 Information about the keys:
 Secret Phrase = Mnemonic phrases (Important keep it Safe)
 Secret Seed = Private Key or Raw Seed (Important keep it Safe)
 Public Key (HEX*) = Account ID (Public Address)
 SS58 Address = SS58-encoded address (Public Address)
ECDSA
The Substrate provides an ECDSA signature scheme using the secp256k1 curve. This is the same cryptographic algorithm used to secure Bitcoin and Ethereum.
Ed25519
​Ed25519 is an EdDSA signature scheme using Curve25519. It is carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security.
SR25519
​SR25519 is based on the same underlying curve as Ed25519. However, it uses Schnorr signatures instead of the EdDSA scheme.
Schnorr signatures bring some noticeable features over the ECDSA/EdDSA schemes:
It is better for hierarchical deterministic key derivations.
It allows for native multi-signature through signature aggregation.
It is generally more resistant to misuse.
One sacrifice that is made when using Schnorr signatures over ECDSA is that both require 64 bytes, but only ECDSA signatures communicate their public key.
1.6 Generate Key pairs with Polkadot-JS
 For more visit the PolkadotJS UI website.
Start with Zentanetwork
1.0 Token Economics
Network ID: Zentanetwork
Symbol: $CHAIN
Algorithm: PoS (Mainnet)
Supply: 5.500.000 (Unofficail)
1.1 Proof of Stake
Proof of stake (PoS) is a type of consensus algorithm by which a cryptocurrency blockchain network aims to achieve distributed consensus. In PoS-based cryptocurrencies, the creator of the next block is chosen via various combinations of random selection and wealth or age (i.e., the stake). In contrast, the algorithm of proof-of-work-based cryptocurrencies such as bitcoin uses mining; that is, the solving of computationally intensive puzzles to validate transactions and create new blocks. 
The main advantages of the Proof of Stake algorithm are energy efficiency and security. A huge number of users are encouraged to run nodes since it’s easy and affordable. This along with the randomization process also makes the network more decentralized, since mining pools are no longer needed to mine the blocks.
Incentives differ between the two systems of block generation. In Proof of Work (PoW), miners may potentially own none of the currency they are mining and thus seek only to maximize their own profits. It is unclear whether this disparity lowers or raises security risks. In Proof of Stake(PoS), however, those "guarding" the coins always own the coins, although several cryptocurrencies do allow or enforce the lending of staking power to other nodes.
1.2 Validation
In the Proof of Stake system, the validation process is done randomly depending on the number of $CHAIN in the wallet account of the people. So every wallet that owns the $CHAIN can become a validator in the network. Of course, accounts with a large number of $CHAIN's in the system are more likely to be used as validation and therefore receive more shares from the network.
Zentanetwork Consensus
Frames
The Framework for Runtime Aggregation of Modularized Entities (FRAME) is a set of modules (called pallets) and supports libraries that simplify runtime development. Pallets are individual modules within FRAME that host domain-specific logic. (Substrate Runtime Modules)
Pallets
​Pallets are a special kind of Rust module from which Substrate runtimes can be composed. Each pallet has its own discrete logic which can modify the features and functionality of your blockchain's state transition function. (A Substrate runtime modules)
Democracy
The Democracy pallet handles the administration of general stakeholder voting. 
Balances
The Balances module provides functionality for handling accounts and balances.
Aura
​Aura provides a slot-based block authoring mechanism. In Aura, a known set of authorities take turns producing blocks.
Grandpa
​GRANDPA provides block finalization. It has a known weighted authority set like BABE. However, GRANDPA does not author blocks; it just listens to gossip about blocks that have been produced by some authoring engine like the three discussed above. GRANDPA validators vote on chains, not blocks, i.e. they vote on a block that they consider "best" and their votes are applied transitively to all previous blocks. Once more than 2/3 of the GRANDPA authorities have voted for a particular block, it is considered final. GRANDPA Abstract paper by Alistair Stewart can be found here.
Finality
The property of a block can not be reverted. Generally, created blocks are not final until some point in the future - perhaps never, in the case of "probabilistic finality".
Babe
​BABE also provides slot-based block authoring with a known set of validators. In these ways, it is similar to Aura. Unlike Aura, slot assignment is based on the evaluation of a Verifiable Random Function (VRF). Each validator is assigned a weight for an epoch.y This epoch is broken up into slots and the validator evaluates its VRF at each slot. For each slot that the validator's VRF output is below its weight, it is allowed to author a block. BABA Abstract by Handan Kılınç Alper can be found here.​
Slots
Slot-based consensus algorithms must have a known set of validators who are permitted to produce blocks. Time is divided up into discrete slots, and during each slot, only some of the validators may produce a block. The specifics of which validators can author blocks during each slot vary from engine to engine. The Substrate provides Aura and Babe, both of which are slot-based block authoring engines.
Epoch
An epoch is a time duration in the BABE protocol that is broken into smaller time slots. Each slot has at least one slot leader who has the right to propose a block.
Era
A (whole) number of sessions, which is the period that the validator set (and each validator's active nominator set) is recalculated and where rewards are paid out.
Runtime
The runtime of a blockchain is the business logic that defines its behavior. In Substrate-based chains, the runtime is referred to as the "state transition function"; it is where Substrate developers define the storage items that are used to represent the blockchain's state as well as the functions that allow blockchain users to make changes to this state.
Validator
Since validator slots will be limited, most of those who wish to stake their Zentachain tokens and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote, and come to a consensus in GRANDPA. Nominators, on the other hand, do not need to do anything once they have bonded their Zentachain tokens.
Nominator
Accounts that select a set of validators to nominate by bonding their Zentachain tokens. Nominators receive some of the validators' rewards but are also liable for slashing if their nominated validators misbehave.
Slashing
Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked Zentachain. Any slashed Zentachain will be added to the Treasury.
Treasury
The Treasury is a pot of funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the Council, will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to governance, with the current default set to 24 days.
Council
The Council primarily serves as a body to optimize and check/balance the more inclusive referendum system. (Election and Proposals)
Timestamp
The Timestamp module allows the validators to set and validate a timestamp with each block. It uses inherents for timestamp data, which is provided by the block author and validated/verified by other validators. The timestamp can be set only once per block and must be set for each block. There could be a constraint on how much time must pass before setting the new timestamp.
​Telemetry Service​
The network information including what nodes are running the chain, what software versions they are running, and sync status.
Session
A session is a Substrate implementation term for a period of time that has a constant set of validators. Validators can only join or exit the validator set at a session change.
Session Keys
Session keys are used by validators to sign consensus-related messages. SessionKeys is a generic, indexable type that is made concrete in the runtime.
Keystore
A subsystem in Substrate for managing keys for the purpose of producing new blocks.
Bonding
A process by which tokens can be "frozen" in exchange for some other benefit. For example, staking is a form of bonding for which you receive rewards in exchange for securing the network.
Extrinsic
State changes that come from the outside world, i.e. they are not part of the system itself.
Zentachain
Zentachain native token is called: 
Name: Zentachain
Symbol: CHAIN
Network: Zentanetwork
Weight
If you are unfamiliar with weights, the TL;DR is that Substrate blockchains have limited resources when it comes to producing new blocks. Most notably, there is a limited window for block producers to create a block, limited amount of data that can be included per block (MaximumBlockLength), and an overall practical limit to the storage footprint of the blockchain.
The Substrate has introduced a Weight system that allows the runtime developer to tell the block production process how “heavy” an extrinsic is. Given some MaximumBlockWeight, and the weight of the individual extrinsics in a transaction pool, we can select the set of extrinsics that allow us to saturate our block, while not going over the limits.
Transaction Fees
When a block author constructs a block, it must limit the block's execution time. A block body consists of a series of extrinsic. Since the resources needed to execute an extrinsic can vary, Substrate provides a flexible mechanism called "weights" to characterize the time it takes to execute an extrinsic. To be economically sustainable and to limit spam, some transactions --- primarily those dispatched by users --- require a fee prior to transaction execution.
To bring the weight system to the users of our blockchain, Substrate introduces a tightly coupled fee system. In short, users will pay a transaction fee proportional to the weight of the call they are making.
1
total_fee = base_fee + length_fee + weight_fee
Copied!
Note: There is also a length_fee which takes into account the amount of data included in an extrinsic.
Sudo
 As the name of the Sudo pallet implies, it provides capabilities related to the management of a single sudo ("superuser do") administrator. In FRAME, the Root Origin is used to identify the runtime administrator; some of the FRAME's features, including the ability to update the runtime by way of the set_code function, are only accessible to this administrator. The Sudo pallet maintains a single storage item: the ID of the account that has access to the pallet's dispatchable functions. The Sudo pallet's sudo function allows the holder of this account to invoke a dispatchable as the Root origin. The Sudo rights will be removed after the main-network and given to the community.
Forkless Upgrades
By using Wasm in Substrate, the framework powering Polkadot, Kusama, and many connecting chains, the chains are given the ability to upgrade their runtime logic without hard forking. Hard forking is a standard method of upgrading a blockchain that is slow, inefficient, and error-prone due to the levels of offline coordination required, and thus the propensity to bundle many upgrades into one large-scale event. By deploying Wasm on-chain and having nodes auto-enact the new logic at a certain block height, upgrades can be small, isolated, and very specific.
WebAssembly (Wasm)
WebAssembly, shortened to simply Wasm, is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. WebAssembly is a platform-agnostic binary format, meaning that it will run the same instructions across whatever machine it is operating on. Blockchains need determinacy in order to have reliable state transition updates across all nodes in the peer-to-peer network without forcing every peer to run the same exact hardware. Wasm is a nice fit for reliability among the possibly diverse set of machines. Wasm is both efficient and fast. The efficiency means that it can be uploaded onto the chain as a blob of code without causing too much state bloat while keeping its ability to execute at near-native speeds.
LibP2P
Libp2p is a network framework that allows you to write decentralized peer-to-peer applications. Originally the networking protocol of IPFS, it has since been extracted to become its own first-class project.
IPFS
The InterPlanetary File System is a peer-to-peer hypermedia protocol designed to make the web faster, safer, and more open.
Smart-contracts
The Contracts pallet provides the ability for the runtime to deploy and execute WebAssembly (Wasm) smart contracts. It uses ink!, a Rust-based embedded domain-specific language (eDSL) for writing WebAssembly smart contracts.
Here are some of ink!'s key features:
Designed for correctness, conciseness, and efficiency, ink! carries familiar concepts from other modern smart contract languages. Learn more about how it compares to Solidity.
ink! provides a built-in test environment that can be used to perform off-chain unit testing with the Rust framework. This makes it simple and easy to ensure that your contract code functions as expected, without the need for third-party testing platforms. Learn more here.
Because ink! follows Rust standards, tools like rustfmt and rust-analyzer already work out of the box.
EVM
FRAME provides an EVM execution pallet that allows unmodified EVM code to be executed in a Substrate-based blockchain. As a key part to Substrate's Ethereum compatibility layer, also known as Frontier, it works together with the Ethereum pallet and the Dynamic Fee pallet to enable the creation of runtimes capable of fully emulating Ethereum block production and transaction processing.
Gas
Contract calls are charged a gas fee to limit the amount of computational resources a transaction can use. When forming a contract transaction, a gas limit is specified. As the contract executes, gas is incrementally used up depending on the complexity of the computation. If the gas limit is reached before the contract execution completes, the transaction fails, contract storage is reverted, and the gas fee is not returned to the user.
Reward calculation
---
Election
---
Rewards
---
Zentachain Networks
Getting Started
Build and get the code
GitHub - ZentaChain/Zentanetwork: Zentanetwork is a forkless Proof of Stake consensus for communication and data storage.
GitHub
Git-Command
1
$ git clone https://github.com/ZentaChain/Zentanetwork
Copied!
Build the CHAIN
1
$ cargo build --release
Copied!
Check Runtime compiles:
1
cargo check -p zentachain-runtime
Copied!
Dev-network
1
$ ./target/release/zentachain --dev
Copied!
Local-network
1
$ ./target/release/zentachain --local
Copied!
Multi-local-networks
1
$ ./target/release/zentachain --chain=local --alice -d /tmp/alice
Copied!
1
$ ./target/release/zentachain ----chain=local --bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/BOOTNODEID'
Copied!
Test-networks
Zajin Network (Beta)
1
$ ./target/release/zentachain --zajin
Copied!
Zentachain Mainnet (Main-net)
1
$ ./target/release/zentachain --zikaron
Copied!
Purge DB
1
$ ./target/release/zentachain purge-chain --chain=ID
Copied!
Help
1
$ ./target/release/zentachain --help
Copied!
Start with Docker
Before you start the network in Docker please make sure you have installed Docker and Composer.
2.2 Install Docker
​Visit: Docker Hub​
2.3 Install Docker Compose
Visit: Compose Hub​
2.4 Run in Docker
1
$ ./scripts/docker_run.sh
Copied!
Advanced Command
--validator 
--bootnode
--name
--chain
--base-path
--chain local
--chain dev
--port
--ws-port
--rpc-port
--telemetry-url
Executed Command
Commands Flags
Flags
Used for Zentanetwork
--alice
Shortcut for --name Alice --validator with session keys for Alice added to keystore
--bob
Shortcut for --name Bob --validator with session keys for Bob added to keystore
--dev
Specify the development chain
--disable-log-color
Disable log color output
--discover-local
Enable peer discovery on local networks
--force-zentachain
Force using Zentachain native runtime
--light
Run in light client mode
--no-grandpa
Disable GRANDPA voter when running in validator mode
--no-mdns
Disable mDNS discovery
--no-telemetry
Disable connecting to the Substrate telemetry server
--one
Shortcut for --name One --validator with session keys for One added to keystore
--two
Shortcut for --name Two --validator with session keys for Two added to keystore
--password-interactive
Use interactive shell for entering the password used by the keystore
--reserved-only
Whether to only synchronize the chain with reserved nodes
--rpc-external
Listen to all RPC interfaces
--storage-chain
Enable storage chain mode
--tmp
Run a temporary node
--unsafe-rpc-external
Listen to all RPC interfaces
--unsafe-ws-external
Listen to all Websocket interfaces
--validator
Enable validator mode
--version
Prints version information
--ws-external
Listen to all Websocket interfaces
--help
Prints help information
--ipfs-server
Join the IPFS network
Commands Option
Option
Used for Zentanetwork
--base-path 
Specify custom base path
--bootnodes 
Specify a list of bootnodes
--chain 
Specify the chain specification
--database 
Select database backend to use
--db-cache 
Limit the memory the database cache can use
--offchain-worker 
Should execute offchain workers on every block
--ipc-path 
Specify IPC RPC server path
--jaeger-agent 
Add the destination address to the jaeger agent.
--keep-blocks 
Specify the number of finalized blocks to keep in the database
--keystore-path 
Specify custom keystore path
--keystore-uri 
Specify custom URIs to connect to for keystore-services
--listen-addr 
Listen on this multiaddress
--name 
The human-readable name for this node
--node-key 
The secret key to use for libp2p networking
--node-key-file
The file from which to read the node's secret key to use for libp2p networking
--node-key-type
The type of secret key to use for libp2p networking
--password
Password used by the keystore
--password-filename
File that contains the password used by the keystor
--port
Specify p2p protocol TCP port
--public-addr
The public address that other nodes will use to connect to it. This can be used if there's a proxy in front of this node
--reserved-nodes
Specify a list of reserved node addresses
--rpc-port
Specify HTTP RPC server TCP port
--sentry
Enable sentry mode
--sentry-nodes
pecify a list of sentry node public addresses
--telemetry-url
The URL of the telemetry server to connect to
--wasm-execution
Method for executing Wasm runtime code
--wasm-runtime-overrides
Specify the path where local WASM runtimes are stored
--ws-max-connections
Maximum number of WS RPC server connections
--ws-port
Specify WebSockets RPC server TCP port
SUBCOMMANDS
Subcommands
Used for Zentanetwork
benchmark
Benchmark runtime pallets
build-spec
Build a chain specification
check-block
Validate blocks
export-blocks
Export blocks
export-state
Export the state of a given block into a chain spec
help
Prints this message or the help of the given subcommand(s)
import-blocks
Import blocks
key
Key management CLI utilities
purge-chain
Remove the whole chain
revert
Revert the chain to a previous state
Chain Network Specification
---
General Errors
--
Explorer Frontend
1.1 Launch the Frontend
Ready to stake Zentachain $CHAIN?
Page not found
Zentachain Docs
Page not found
Zentachain Docs
License
Substrate Primitives (sp-*), Frame (frame-*) and the pallets (pallets-*), binaries (/bin) and all other utilities are licensed under Apache 2.0.
Substrate Client (/client/* / sc-*) is licensed under GPL v3.0 with a classpath linking exception.
GPL V3
The reason for the split-licensing is to ensure that for the vast majority of teams using Substrate to create feature-chains, then all changes can be made entirely in Apache2-licensed code, allowing teams full freedom over what and how they release and giving licensing clarity to commercial teams.
In the interests of the community, we require any deeper improvements made to Substrate's core logic (e.g. Substrate's internal consensus, crypto or database code) to be contributed back so everyone can benefit.
References:
Substrate: https://substrate.dev​
Proof of Work: https://en.wikipedia.org/wiki/Proof_of_work​
Proof of Stake: https://de.wikipedia.org/wiki/Proof_of_Stake​
Ethereum: https://ethereum.org/en/whitepaper​
Polkadot: https://polkadot.network/PolkaDotPaper.pdf​
Alistair Stewart: https://research.web3.foundation/en/latest/polkadot/finality.html?highlight=grandpa#polite-grandpa​
Handan Kılınç Alper: https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html​
Web3 Foundation: https://web3.foundation​
Zentachain: https://zentachain.io​
Zentachain Github: https://github.com/ZentaChain/Zentanetwork​
Zentachain Whitepaper: https://zentachain.io/documents/Zentachain_Whitepaper.pdf​
​
Zentachain
Economics
Last modified 3mo ago