RETchain Testnet is live!

Getting started and interaction guide

The RealTract team is extremely proud to launch our RETchain Testnet. This is a crucial milestone for the strong development of the project at present and in the future. RealTract team has built and tested thoroughly and would now like to present it to the community to test and carefully consider your feedback before the launch of the much-awaited mainnet.

As previously announced, the RETchain Testnet process will be divided into several stages, meaning this is not the final version of Testnet. There will be many more versions to be released for the community to review before the official launch of the mainnet.

Testnet Version 1 uses Proof-of-Authority (PoA) along with a suite of tools including RETchain explorer, Validator smart contract, and Privacy smart contract which allows sending token privately.

Get familiar with our technology.

To get a general architecture overview and understanding of how the basic blockchain components interact, please check out RealTract Whitepaper Version 3

Testnet token faucet function.

You can participate in setting up, creating an account and receiving the RET Testnet token by linking with Metamask. The procedure is as follows:

Step 1: Log in to your Metamask account. If you have not already installed Metamask for your browser, please refer to this link

Step 2: In the Network Conversion window, select Custom RPC. Fill in the following information in the Setting field and then click Save:

Step 3: Go to http://validator.realtract.network/faucet , enter the address of the RETchain Testnet wallet obtained from Metamask and click Claim to receive the RET Token Testnet.

Send/Receive RET token Testnet

Users can send/receive RET token Testnest obtained from Faucet function through Metamask

RETchain Explorer

RETchain Explorer is a tool for inspecting and analyzing RETchain.

http://explorer.realtract.network/

Privacy Smart Contract

http://validator.realtract.network:8080

Anonymous cross-border money transfer demonstration (Privacy)

1. Login:

- Sign with msg:LOGIN:{address}.

- Get the Metamask account’s Public Key (PK) from signature.

- Viewing Private Key (VPK) will be generated from the signature. VPK will only be used to decrypt note’s value.

- The PK and Viewing Public Key (VK) of the Metamask account (the Receiver) will be sent to the Sender.

2. Demo:

- Convert Rcoin to ERC20 Rtoken (1 Rcoin = 1 Rtoken, 18 decimals).

- Convert ERC20 Rtoken to Confidential Token with a scaling factor of 1e18.

- Confidential Transfer (the transfer amount is encrypted).

- Convert Confidential Token to ERC20 Rtoken.

- Convert ERC20 Rtoken back to Rcoin.

3. Confidential transfer mechanism:

- All note’s VK will be encrypted with receiver’s VK and submitted on-chain. These processes could be handled off-chain with trading channels, where senders send encrypted note’s Viewing Keys to receivers.

- Once logged in, a Dapp would listen to pastEvents to make spent and unspent notes. You decrypt the note’s value with VPK.

- This confidential transfer works basically like UTXO models with unknown note’s value and Zero-Knowledge to guarantee that inputs’ sum is equal to outputs’ sum.

4. Example: Alice wants to send X1 tokens to Bob1, X2 tokens to Bob2.

A. Bob send public key to Alice.

B. Alice create a Note as an Output1 from Bob1’s public key P1(Bob is node’s owner) with value=X1 and encrypts the node with a viewing key V1(to see full details of node value, owner). Do the same with Bob2 and got Output2(X2, V2, P2)

C. Alice owns some unspent Nodes(Input 1 … Input N) with sum= S >= X1 + X2. She creates some Notes as Rest Ouputs(could be dummy notes with value 0) with her Public Key and same Viewing Key(easy to control) with sum = R = S — X1 — X2.

D. Alice create a Tx with selected Inputs and created Nodes(of Bob1, Bob2 and herself)

E. Without Viewing Key, Nobody can read the value of each note. with ZK’s help, contract can only verify Sum(Inputs) = Sum(Outputs) for correctness.

F. Alice sends the V1 to Bob1, V2 to Bob2, so they can verify their incoming note.

Gas Station

Demonstration of anti-spam capacities (the network cannot be clogged by the likes of CryptoKitties) and gas loyalty (the more gas a node contritbute to the network, the less gas it needs to prioritize its transactions later on)

1. Each account will have 1 X factor (0<= X <= 0.5). An account with higher total amount of spent FEE (accountFee) will have a higher X.

2. At the moment, if accountFee >= 1/1000 * The network’s total spent Fee, its X will reach 0.5.

3. For every 1 tx, the sealer will receive X * Fee. The remaining amount of fee = (1-X) * Fee will be burnt by being sent to 0x0.

4. The priority of a tx in the queuing tx pool is = gasPrice * X, instead of the gasPrice in the cases of most popular blockchains, favoring accounts which have spent more fee on the network, allowing them to spend less and less to maintain a high priority of their transactions in the tx pool.

Validator Staking

http://validator.realtract.network/

Coin staking demonstration

Any validator can deposit/withdraw coins, join/leave as validator, claim reward, and report faulty validators, helping investors participate in RET mining more informedly. The list of reported validators will be updated in real time.

1. The list of validators is updated in real time (Joining/Leaving activities).

2. StakeRequired = CoinSupply/1000 (tentative) or 3 genesis validators bypass this.

3. Safe Range (SR) = 2 * N (tentative) in blocks

- 2 consecutive reports on the same validator must be at least SR blocks apart.

- A validator can only be reported after joining for at least SR blocks.

- A validator can only if the last blocked sealed by it is SR blocks apart from the current block.

- After SR blocks, transactions cannot be reverted.

4. Block reward is shared in a pool among all validators. Therefore, after every block, the amount of reward received by each validator only increases.

5. After being claimed, reward will be locked for a lock range (LR) of 10*N blocks and added to “Frozen Balance,” until it can be cashed out.

6. After sealing every 6 blocks, a validator will receive 1 Loyalty Point. A validator’s Total LP is always <= the number of times being penalized + 3, and never decreases.

7. After every successful reporting, the reporting validator will receive 1 RP.

8. When reported, if the reported validator’s LP is >= the number of times being penalized, its penalty will be only the base amount (as a percentage of the total stake).

9. When reported, if the reported validator’s LP is < the number of times being penalized, the penalty will be the base amount times 2^k (with k = the number of times being penalized minus LP).

10. When penalized, if the Frozen Balance is sufficient, it will be deducted by the amount being distributed to validators proportionally to their share of stake.

11. When penalized, if the Frozen Balance is insufficient, the reward balance of the validator will be liquidated (automatically claimed and moved to the Frozen Balance).

12. If the Reward Balance is also insufficient, the penalized Validator will be automatically force-kicked out, all staked amount be unstaked and deducted up to the remaining penalty.

Building the source

For prerequisites and detailed build instructions please read the Installation Instructions below.

Installation Instructions for Linux/Unix

(You can use Linux/Unix servers of DigitalOcean, AWS, etc.)

Update package manager and install git

sudo apt-get update && sudo apt-get -y upgrade
sudo apt-get install git

Clone the repository to a directory of your choosing:

git clone https://github.com/RealTract/RETchain.git

Install latest distribution of Go if you don’t have it already. You can refer to below document guide to install Go on Ubuntu 18.04

https://www.digitalocean.com/community/tutorials/how-to-install-go-on-ubuntu-18-04

Building rchain requires both a Go (version 1.10 or later) and a C compiler. You can install them using your favourite package manager.

sudo apt-get install -y build-essential

Once the dependencies are installed. Finally, build the rchain program using the following command.

cd RETchain
make rchain

or, to build the full suite of utilities:

make all

You can now run build/bin/rchain to start your node.

Running RETchain

Going through all the possible command line flags is out of scope here, but we’ve enumerated a few common parameter combos to get you up to speed quickly on how you can run your own rchain instance.

Validator node on the RETchain network

Create an rchain account to sign the block for the validator

./build/bin/rchain account new

It will promtly you to input password for the new account. And take node that Your new account is locked with a password. Please give a password. Do not forget this password.. For example, we input 123456 as password.

After you input matched password and repeat password of 123456, a new account was generated something like following

Your new key was generated
Public address of the key:   e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb
Path of the secret key file: /root/.rchain/keystore/UTC--2019-11-05T15-46-35.685344950Z--e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb
- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

To unlock account in the cli for signing, we will firstly write out the account password above into a file named passwd by running echo 123456 > passwd then passing the passwd file name into --password option to run validator node as below.

Run node as validator with --mine cli option as below, we also need to unlock the etherbase account with password. For instance, we run validator node with account e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb

nohup ./build/bin/rchain --mine --unlock e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb --password passwd --etherbase e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb

Then come to rchain validator dapp to deposit and register validator with coinbase of e94d5a92aeacaff99fe1ab6988ddb3e66c9fd4eb that we unlock on above.

Full node on the RETchain network

By far the most common scenario is people wanting to simply interact with the RETchain network: create accounts; transfer funds; deploy and interact with contracts. For this particular use-case the user doesn’t care about years-old historical data, so we can fast-sync quickly to the current state of the network. To do so:

$ rchain console

This command will:

• Start rchain in fast sync mode (default, can be changed with the --syncmode flag), causing it to download more data in exchange for avoiding processing the entire history of the RETchain network, which is very CPU intensive.
• Start up rchain's built-in interactive JavaScript console, (via the trailing console subcommand) through which you can invoke all official web3 methods as well as rchain's own management APIs. This tool is optional and if you leave it out you can always attach to an already running rchain instance with rchain attach.

Programmatically interfacing rchain nodes

As a developer, sooner rather than later you’ll want to start interacting with rchain and the RETChain network via your own programs and not manually through the console. To aid this, rchain has built-in support for a JSON-RPC based APIs. These can be exposed via HTTP, WebSockets and IPC (UNIX sockets on UNIX based platforms, and named pipes on Windows).

The IPC interface is enabled by default and exposes all the APIs supported by rchain, whereas the HTTP and WS interfaces need to manually be enabled and only expose a subset of APIs due to security reasons. These can be turned on/off and configured as you'd expect.

HTTP based JSON-RPC API options:

• --rpc Enable the HTTP-RPC server
• --rpcaddr HTTP-RPC server listening interface (default: localhost)
• --rpcport HTTP-RPC server listening port (default: 8545)
• --rpcapi API's offered over the HTTP-RPC interface (default: eth,net,web3)
• --rpccorsdomain Comma separated list of domains from which to accept cross origin requests (browser enforced)
• --ws Enable the WS-RPC server
• --wsaddr WS-RPC server listening interface (default: localhost)
• --wsport WS-RPC server listening port (default: 8546)
• --wsapi API's offered over the WS-RPC interface (default: eth,net,web3)
• --wsorigins Origins from which to accept websockets requests
• --ipcdisable Disable the IPC-RPC server
• --ipcapi API's offered over the IPC-RPC interface (default: admin,debug,eth,miner,net,personal,shh,txpool,web3)
• --ipcpath Filename for IPC socket/pipe within the datadir (explicit paths escape it)

You’ll need to use your own programming environments’ capabilities (libraries, tools, etc) to connect via HTTP, WS or IPC to a rchain node configured with the above flags and you'll need to speak JSON-RPC on all transports. You can reuse the same connection for multiple requests!

Note: Please understand the security implications of opening up an HTTP/WS based transport before doing so! Hackers on the internet are actively trying to subvert rchain nodes with exposed APIs! Further, all browser tabs can access locally running web servers, so malicious web pages could try to subvert locally available APIs!

Testnet goals

Once everything is diligently tested during the testnet with improvements and tweaks made over multiple testnet iterations, we will move towards launching the mainnet. At this point, we’re eager to collect feedback from the community and improve RETchain Protocol. Please contribute by sharing insights you’ve got to our Telegram group or pull requests on GitHub.