Giter Club home page Giter Club logo

ever-node's Introduction

ever-node

Everscale/Venom node and validator with tools

Table of Contents

About

Implementation of Everscal/Venom node and validator in safe Rust. This repository also contains a collection of tools used to manage the Everscale/Venom node.

Getting Started

Prerequisites

Rust complier v1.76+.

apt-get update
apt-get install pkg-config make clang libssl-dev libzstd-dev libgoogle-perftools-dev

Installing

git clone --recurse-submodules https://github.com/everx-labs/ever-node.git
cd ever-node
cargo build --release

Running tests

cargo test --release --package catchain -- --nocapture --test-threads=1 
cargo test --release --package storage -- --nocapture --test-threads=1 
cargo test --release --package validator_session -- --nocapture --test-threads=1 
cargo test --release -- --nocapture --test-threads=1

Everscale/Venom Node Usage

To get help about command line arguments, run

ever-node --help

Everscale/Venom Console Usage

This tool serves the purpose of generating election requests for the Rust Node. The tool is compatible with TONOS-CLI and allows to perform all actions necessary to obtain a signed election request.

How to use

console -C console.json -c "commamd with parameters" -c "another command" -t timeout

Where

console.json - path to configuration file

commamd with parameters/ another command – any of the supported console commands with necessary parameters

timeout – command timeout in seconds

Configuration file should be created manually and have the following format:

{
		"config": {
				"server_address": "127.0.0.1:4924",
				"server_key": {
						"type_id": 1209251014,
						"pub_key": "cujCRU4rQbSw48yHVHxQtRPhUlbo+BuZggFTQSu04Y8="
				},
				"client_key": {
						"type_id": 1209251014,
						"pvt_key": "oEivbTDjSOSCgooUM0DAS2z2hIdnLw/PT82A/OFLDmA="
				}
		},
		"wallet_id": "-1:af17db43f40b6aa24e7203a9f8c8652310c88c125062d1129fe883eaa1bd6763",
		"max_factor": 2.7
}

Where

server_address – address and port of the node.

server_key – structure containing server public key. Can be generated with keygen tool.

client_key – structure containing client private key. Can be generated with keygen tool.

type_id – key type, indicating ed25519 is used. Should not be changed.

wallet_id – validator wallet address.

max_factormax_factor stake parameter (maximum ratio allowed between your stake and the minimal validator stake in the elected validator group), should be ≥ 1

Commands

addadnl

addadnl – sets key as ADNL address.

params:

perm_key_hash - ed25519 hash of permanent public key in hex or base64 format.

key_hash - ed25519 hash of public key in hex or base64 format.

expire-at - time the ADNL address expires and is deleted from node, in unixtime.

Example:

console -c "addadnl 4374376452376543 6783978551824553 1608288600"

addpermkey

addpermkey - adds validator permanent key

params:

key_hash - ed25519 hash of public key in hex or base64 format.

election-date - election start in unixtime.

expire-at- time the key expires and is deleted from node, in unixtime.

Example:

console -c "addpermkey 4374376452376543 1608205174 1608288600"

addtempkey

addtempkey - adds validator temporary key.

params:

perm_key_hash - ed25519 hash of permanent public key in hex or base64 format.

key_hash - ed25519 hash of public key in hex or base64 format.

expire-at - time the key expires and is deleted from node, in unixtime.

Example:

console -c "addtempkey 4374376452376543 6783978551824553 1608288600"

addvalidatoraddr

addvalidatoraddr - adds validator ADNL address.

params:

perm_key_hash - ed25519 hash of permanent public key in hex or base64 format.

key_hash - ed25519 hash of public key in hex or base64 format.

expire-at- time the ADNL address expires and is deleted from node, in unixtime.

Example:

console -c "addvalidatoraddr 4374376452376543 6783978551824553 1608288600"

election-bid

election-bid - obtains required information from the blockchain, generates all the necessary keys for validator, prepares the message in predefined format, asks to sign it and sends to the blockchain.

params:

election-start - unixtime of election start.

election-end - unixtime of election end.

filename - filename with path to save body of message ("validator-query.boc" by default)

Example:

console -c "election-bid 1608205174 1608288600"

Command calls all other necessary subcommands automatically. Election request is written to file.

exportpub

exportpub - exports public key by key hash.

params:

key_hash - ed25519 hash of public key in hex or base64 format.

Returns public_key - ed25519 public key in hex and base64 format.

Example:

console -c "exportpub 4374376452376543"

getaccount

getaccount - load and save (optional) account information in json-format.

params:

account_address - is the account address.

file_name - is the file's name to save account information in json-format. This param is optional.

Returns json with account information.

Base json-fields:

acc_type - account type description;

balance - account balance;

last_trans_lt - logical time of the last account's transaction;

data(boc) - account`s boc.

Example:

console -c "getaccount 0:000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F"

getaccountstate

getaccountstate - save account to the file (in bag of cells format).

params:

account_address - is the account address.

file_name - is the file's name to save account's boc.

Returns account's boc.

Example:

console -c "getaccountstate 0:000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F account.boc"

getblockchainconfig

getblockchainconfig - get current config from masterchain state.

Returns boc with current config.

Example:

console -c "getblockchainconfig"

getconfig

getconfig - get current config param from masterchain state.

params:

param_number - config parameter number.

Returns boc with current config param.

Example:

console -c "getconfig 15"

getstats

getstats - get node status, validation status (if node is validator) and other information.

Command has no parameters.

Returns node's information in JSON-format.

base json-fields:

sync_status - synchronization status description;

masterchainblocktime - field with time of last masterchain block, downloaded by node;

masterchainblocknumber - field with number of last masterchain block, downloaded by node;

timediff - field with time difference between now and last loaded masterchain block's time;

in_current_vset_p34 - true, if config param p34 contains this node's key;

in_current_vset_p36 - true, if config param p36 contains this node's key;

last applied masterchain block id - field with information about last applied masterchain block's id;

processed workchain - field with information about the processed workchain;

validation_stats - field with information about validated workchains;

tps_10 - transactions per second average over 10 seconds;

tps_300 - transactions per second average over 300 seconds;

Example:

console -c "getstats"

newkey

newkey - generates new key pair on server.

Command has no parameters.

Returns ed25519 hash of public key in hex and base64 format.

Example:

console -c "newkey"

recover_stake

recover_stake – recovers all or part of the validator stake from elector.

params:

filename - filename with path to save body of message ("recover-query.boc" by default)

Example:

console -c "recover_stake"

sendmessage

sendmessage - loads a serialized message from file and sends it to nodes as an external message.

params:

file_name - serialized message file (in bag of cells format).

Example:

console -c "sendmessage message.boc"

sign

sign - signs bytestring with private key.

params:

key_hash - ed25519 hash of public key in hex or base64 format.

data - data in hex or base64 format.

Example:

console -c "sign 4374376452376543 af17db43f40b6aa24e7203a9f8c8652310c88c125062d1129f"

Zerostate tool

This tool generates config and zerostate for network launch from json zerostate file.

How to use

zerostate -i zerostate.json

Where

zerostate.json – is the zerostate file.

Keygen tool

This tool generates an Ed25519 key and prints it out in different formats.

How to use

keygen

Command has no parameters.

Gendht tool

This tool generates the node DHT record, for example, for the purposes of adding it to the global blockchain config.

How to use

gendht ip:port pvt_key

Where

ip:port – Node IP address and port.

pvt_key – Node private key.

Example:

gendht 51.210.114.123:30303 ABwHd2EavvLJk789BjSF3OJBfX6c26Uzx1tMbnLnRTM=

Dhtscan tool

This tool scans DHT for node records.

How to use

dhtscan [--jsonl] [--overlay] [--workchain0] path-to-global-config

Where

--jsonl – optional flag that sets the output as single line json. Default output is multiline json.

--overlay – optional flag to search for overlay nodes.

--workchain0 – optional flag to search both in masterchain and basechain. By default only masterchain is searched.

path-to-global-config – path to network global config file.

Print tool

This tool prints a state or block from the database.

How to use

print -d path [-s state_id] [-b block_id] [--accounts]

Where

path – path to node database.

block_id – id of the block to be printed.

state_id – id of the state to be printed.

accounts - short info of all accounts will be printed as json

Contributing

Contribution to the project is expected to be done via pull requests submission.

License

See the LICENSE file for details.

Tags

blockchain everscale rust venom-blockchain venom-developer-program venom-node venom-validator

ever-node's People

Contributors

0xdeafbeef avatar antonivanchukov avatar ar-tmp avatar atomxy avatar bvscd avatar lenykholodov avatar serejkaaa512 avatar sumrachek avatar tonjen avatar yaroslavser avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ever-node's Issues

Do not delete frozen accounts.

The storage size of a frozen account is minimal, about 1 cell and 327 bits, as it only stores the hash of the stateInit. Currently, accounts are deleted when their debt(due) exceeds 1 ever. However, if an account is frozen with a balance near 0, the time before it is deleted is more than 30 years.

For safety reasons, we propose not to delete frozen accounts. This will ensure that the account remains in the blockchain and can be unfrozen and used again in the future if needed.

No storage due payment on credit phase from bouncable message

Abstract

This document describes the changes in collecting storage fee receiving bouncable message

Motivation

Currenly we cannot predict the amount of tokens for storage fee and due payment. So we cannot be sure to receive bounced message in case of incorrect produce. Since we don't want to apply too much value especially since it's still not a guarantee.

Specifications

For bouncable message we don't want to use its value for any storage payment. So if account is coming to due payment state it will accumulate.

build error

I am getting this error while building:
Compiling ton_api v0.0.1 (https://github.com/tonlabs/ton-labs-tl.git#8117a829)
error: failed to run custom build command for ton_api v0.0.1 (https://github.com/tonlabs/ton-labs-tl.git#8117a829)

Caused by:
process didn't exit successfully: /mnt/f/DATA/Documents/Work/ton-labs-node/target/release/build/ton_api-e235b54108fe1794/build-script-build (exit code: 101)
--- stdout
cargo:rerun-if-changed=src/ton
cargo:rerun-if-changed=tl
cargo:rerun-if-changed=../ton_tl_codegen
cargo:rerun-if-changed=tl/lite_api.tl
cargo:rerun-if-changed=tl/ton_api.tl
cargo:rerun-if-changed=tl/ton_net.tl
cargo:rerun-if-changed=tl/tonlib_api.tl

How to resolve this error

1700213031.273338034 WARN [ton_node::network::neighbours] 139696071001856: Capabilities were not received from MXfG/zYVL747/eND1E3Lkj8H3tyJ403pYtdurK+MbBE= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213031.656882459 WARN [ton_node::network::neighbours] 139696054191872: Capabilities were not received from GcdMHKDvDH5gT/VQhiDbU1IKc5V4IOe1QqcegU74g5A= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213031.940775284 WARN [boot] 139696106994688: check_proof error: Invalid TL-B constructor tag #9bc7a988 while parsing BlockInfo struct
1700213032.356568315 WARN [ton_node::network::neighbours] 139696012166912: Capabilities were not received from VqtVjgjdfGDb1lNNWPudEBWU4kF9mcGn87bbWDEhwtc= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213033.568022240 WARN [ton_node::network::neighbours] 139695911307008: Capabilities were not received from 7JIjPZlQdoMnfV9hhz0ZJwrgQT/MZlMc4JLQSdeXC1Y= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213033.569782727 WARN [boot] 139696106994688: check_proof error: Invalid TL-B constructor tag #9bc7a988 while parsing BlockInfo struct
1700213033.671034278 WARN [ton_node::network::neighbours] 139696012166912: Capabilities were not received from uQi5WIaPvQbwb+9Dhwv0885G+oeF7q8IYWta3Q2Fju0= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213033.838116622 WARN [ton_node::network::neighbours] 139695978546944: Capabilities were not received from 4v/qCPbLRA9MwALrwdShYhrc7RrY0fALuWvVMY8oB3Y= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213033.863737271 WARN [ton_node::network::neighbours] 139696045786880: Capabilities were not received from cUEyOXwkokzSEYOh0QvmYgOmMc4Zd/OLHA3SpeesG2M= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213035.194965273 WARN [boot] 139696106994688: check_proof error: Invalid TL-B constructor tag #9bc7a988 while parsing BlockInfo struct
1700213036.285296230 WARN [ton_node::network::neighbours] 139696045786880: Capabilities were not received from xfQypu84m69cC9/gUT7jfP/XHqXKl2FNGsghAjZKUVc= Wazq6hhjvNjq68AlHctgXrCHMLlLCdgj+Y23DklOpNc= src/network/neighbours.rs:658
1700213036.335415524 INFO [telemetry] 139696012166912:

Mint, burn and send extra currencies

Abstract

This document describes the principles of working with non-native tokens at the network protocol level.

Motivation

Currently, work with non-native tokens is implemented on smart contracts using the TIP3 standard. At the same time, at the protocol level it is possible to create and transfer non-native tokens, which allows

  • Transfer more than one token at a time in one transaction
  • Control value flow at the protocol level using validators.

The current implementation of currency collection has shortcomings

  • no burn tokens (only transfer to burn address)
  • creating a new token or minting existing ones requires changing the global network config
  • Mint occurs at minter's address

This proposal is intended to correct shortcomings and make working with currency collection accessible to any network participant
This proposal is not intended to replace the TIP3 standard, but rather to enhance its capabilities.

Specifications

We propose to add a system smart contract that will allow you to

  • create new currencies
  • transfer tokens without reducing its balance (mint operation)
  • not change its balance when receiving tokens (burn operation)

Description of Manager Currencies smart contract

  • function register_new_token()
  • function mint(uint256 value, address addr)
  • function burn()

The operation of the contract cannot be completely free, even if it is made systemic, it should still require tokens for the operations of adding currency and minting tokens, as part of spam protection.

Modify virtual machine

Add a tvm.burn instruction that creates OutAction::Burn
Validators only allow this instruction to be used for addresses from global config

Pros and Cons:

What is the upside of using Currency collection?

  • We will be able to reduce the chain of token transfers between users
  • We will be able to transfer multiple tokens in a single transaction (as in 1155)
  • We will be able to use for MESH networks

What are the downsides of using Currency collection?

  • It seems that DEX will have to support both TIP3 and currency, more code to write in pools, legs, etc.
  • Mint and burn is a load on the master and can't be a cheap operation
  • Not suitable for CBDC
  • Load on masterchain

Why burn only for contracts from master

When we burn we change global balance in the blockchain state and it is stored at masterchain

Build error.

Hi,

I am setting up the validator node. while setting up, The below command gives the error. Also before running the build command, Ran the below commands

         git submodule init
        git submodule update

#cargo build --release

root@3002d3806db1:/tonlabs/ton-node# cargo build --release
    Updating git repository `https://github.com/tonlabs/ton-labs-adnl`
    Updating crates.io index
    Updating git repository `https://github.com/tonlabs/lockfree.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-tl`
    Updating git repository `https://github.com/tonlabs/ton-labs-block`
    Updating git repository `https://github.com/tonlabs/ton-labs-types`
    Updating git repository `https://github.com/rust-rocksdb/rust-rocksdb.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-dht`
    Updating git repository `https://github.com/tonlabs/ever-labs-crypto`
    Updating git repository `https://github.com/tonlabs/ton-labs-overlay`
    Updating git repository `https://github.com/tonlabs/ton-labs-rldp`
    Updating git repository `https://github.com/tonlabs/ton-labs-abi.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-block-json.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-executor`
    Updating git repository `https://github.com/tonlabs/ton-labs-vm`
error: failed to select a version for `zstd-sys`.
    ... required by package `zstd-safe v4.0.0+zstd.1.4.9`
    ... which satisfies dependency `zstd-safe = "=4.0.0"` of package `zstd v0.8.0+zstd.1.4.9`
    ... which satisfies dependency `zstd = "^0.8"` of package `adnl v0.7.74 (https://github.com/tonlabs/ton-labs-adnl?tag=0.7.74#4f2335e0)`
    ... which satisfies git dependency `adnl` of package `catchain v0.1.0 (/tonlabs/ton-node/catchain)`
    ... which satisfies path dependency `catchain` of package `ton_node v0.50.21 (/tonlabs/ton-node)`
versions that meet the requirements `=1.5.0` are: 1.5.0+zstd.1.4.9

the package `zstd-sys` links to the native library `zstd`, but it conflicts with a previous package which links to `zstd` as well:
package `zstd-sys v2.0.0+zstd.1.5.2`
    ... which satisfies dependency `zstd-sys = "^2.0"` of package `librocksdb-sys v0.7.1+7.3.1 (https://github.com/rust-rocksdb/rust-rocksdb.git#39dc822d)`
    ... which satisfies git dependency `librocksdb-sys` of package `rocksdb v0.18.0 (https://github.com/rust-rocksdb/rust-rocksdb.git#39dc822d)`
    ... which satisfies git dependency `rocksdb` of package `storage v0.5.0 (/tonlabs/ton-node/storage)`
    ... which satisfies path dependency `storage` of package `catchain v0.1.0 (/tonlabs/ton-node/catchain)`
    ... which satisfies path dependency `catchain` of package `ton_node v0.50.21 (/tonlabs/ton-node)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='zstd-sys' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

failed to select a version for `zstd-sys` which could resolve this conflict

Any advice ?

unable to install this broken software

hey,

i followed the official instructions, build failed, installed the unlisted dependency, build failed, installed the unlisted dependency, and now here we are @ Building [=======================> ] 480/481: ton_node(bin) at the end of a lengthy build attempt.

  = note: /usr/bin/ld: cannot find -ltcmalloc: No such file or directory
          collect2: error: ld returned 1 exit status


warning: `ton_node` (bin "ton_node") generated 1 warning (1 duplicate)
error: could not compile `ton_node` due to previous error; 1 warning emitted
root@1999:~/ton-labs-node#

any help?

Enable and improve libraries

Abstract

This document describes the storage and utilization of library functions for use in smart contracts.

Motivation

At present, smart contract developers store all smart contract code in a single account. Consequently, they are compelled to repeatedly upload redundant code to the blockchain. If an error or suboptimal code is found within a function, developers must update all smart contracts using that function.

Specifications

Add the following functionality:

  • Each account can add/modify/delete library functions if the corresponding logic is implemented within it.

  • Each account pays the storage fee for its own library functions.

  • Each account using libraries pays gas fees for loading and executing library functions.

  • Libraries stored on the master chain are visible on the master chain and on work chains.

  • Libraries stored on a work chain are visible only to that work chain.

Changes at the blockchain state level

  • The key of the library is considered to be a hash of the initial code and the account address.

  • Limit the number of libraries per account to 250.

  • Store libraries for workchains.

Changes at the VM level

  • Create instructions for updating library code.

Changes at the account level

No changes required.

Cost of storing the library

No changes required.

Cost of loading and using the library

No changes required.

Library upload process

No changes required.

Library modification process

No changes required.

Library usage process

No changes required.

The node does not start on FreeBSD 12.2-RELEASE-p3

Some packages on 12.1 become deprecated and I had to upgrade to 12.2.
Building the node goes fine (commit bc5e910 from 10.02), but it did not start with error:

2021-02-11 14:06:09.820824742 INFO [ton_node::engine] 34412036096: Engine::run
2021-02-11 14:06:09.820848166 INFO [ton_node::engine] 34412036096: Creating engine...
2021-02-11 14:06:09.935534536 TRACE [ton_node::internal_db] 34412036096: load_node_state InitMcBlockId
2021-02-11 14:06:09.937459468 ERROR [ton_node] 34412036096: Can't start node's Engine: Os { code: 55, kind: Other, message: "No buffer space available" }
2021-02-11 14:06:09.937523662 WARN [adnl::node] 34418900736: Sent query 62ab6945
2021-02-11 14:06:09.937833249 WARN [adnl::node] 34418916096: Sent query ae7170b8
2021-02-11 14:06:09.937903225 WARN [adnl::node] 34418914816: Sent query 16be0187

Any comments?

Add BLS12-381 support

Abstract

The document describes the changes necessary to make in the virtual machine to support BLS12-381

Motivation

Support for BLS12-381 will allow the implementation of new mechanics in the everscale network. It can be used by ZK-protocols.

Specifications

Implement in VM all the necessary primitives for working with BLS12-381

  • Checks BLS signature
  • Aggregates signatures.
  • Addition\Subtraction\Negation on G1
  • Addition\Subtraction\Negation on G2
  • others

Rationale

Why BLS12-381?

At this point, BLS12-381 seems to be the rational choice due to the multiple reasons

  • Growing support in the industry. Different projects are using this curve to make use of aggregatable signatures (validator's signatures in Ethereum Beacon chain/Account Abstraction multi-signature wallets/etc)
  • Keeping compatibility with the TON network

StatsD metric is broken if its name contains colon

Examples of statsd complaining about bad metrics:

DEBUG: Bad line: a800000000000000 in msg "rnode.succeessful_validations_0:a800000000000000:1|c"
DEBUG: Bad line: 8000000000000000 in msg "rnode.run_validators_-1:8000000000000000:1|c"
DEBUG: Bad line: 8000000000000000 in msg "rnode.gas_rate_validator_-1:8000000000000000:222|g"

node crashes at `ZSTD_freeDDict` while compression enabled

# lldb
(lldb) target create -core /opt/freeton/db/rnode28.itgold.io.12064.10.ton_node.core /usr/local/src/freeton/release/ton_node
Core file '/opt/freeton/db/rnode28.itgold.io.12064.10.ton_node.core' (x86_64) was loaded.

(lldb) thread backtrace all
* thread #1, name = 'tokio-runtime-worke', stop reason = signal SIGBUS
  * frame #0: 0x00000000023a62b1 ton_node`ZSTD_freeDDict + 17
    frame #1: 0x0000000802a6951d libzstd.so.1`ZSTD_DCtx_loadDictionary + 61
    frame #2: 0x0000000001967d5e ton_node`adnl::node::DataCompression::decompress::h2be652aaafabca00 + 974
    frame #3: 0x00000000014f5b32 ton_node`rldp::RldpNode::query_transfer::_$u7b$$u7b$closure$u7d$$u7d$::h81726438b81b92e4 + 22546
    frame #4: 0x00000000016dddd8 ton_node`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::he2a8531efc22c538 + 1240
    frame #5: 0x00000000016d0353 ton_node`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::hc24f94e266a001cc + 8867
    frame #6: 0x00000000016c80cf ton_node`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::ha759023c71853c82 + 271
    frame #7: 0x000000000158810c ton_node`tokio::runtime::task::harness::poll_future::h7592781cda975e13 + 588
    frame #8: 0x000000000153ec86 ton_node`tokio::runtime::task::raw::poll::hb86faf8af2e771e1 + 166
    frame #9: 0x0000000001d26e63 ton_node`tokio::runtime::thread_pool::worker::Context::run_task::h7d05eb97c8d2b807 + 227
    frame #10: 0x0000000001d24f02 ton_node`tokio::runtime::task::raw::poll::h8a56ef0fb12d77c7 + 2514
    frame #11: 0x0000000001d1369f ton_node`std::sys_common::backtrace::__rust_begin_short_backtrace::hfbd1a16d3c59124a + 543
    frame #12: 0x0000000001d13386 ton_node`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h9c6b4e7d6be3456f + 150
    frame #13: 0x0000000001cae91d ton_node`std::sys::unix::thread::Thread::new::thread_start::h36f97e85540097b5 + 45
    frame #14: 0x0000000802ab3859 libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 329
  thread #2, name = 'ton_node', stop reason = signal SIGBUS
    frame #0: 0x0000000802ab0b7c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 12
    frame #1: 0x0000000802ac0720 libthr.so.3`___lldb_unnamed_symbol186$$libthr.so.3 + 80
    frame #2: 0x0000000802ab26df libthr.so.3`___lldb_unnamed_symbol7$$libthr.so.3 + 623
    frame #3: 0x0000000001d0c8e3 ton_node`tokio::park::thread::Inner::park::h709e2317ab01253c + 163
    frame #4: 0x000000000190818b ton_node`ton_node::main::h39c3efe93663b1c8 + 21867
    frame #5: 0x0000000001465cfa ton_node`std::sys_common::backtrace::__rust_begin_short_backtrace::h0d6bba560d1d3c56 + 10
    frame #6: 0x000000000194ab96 ton_node`main + 726
    frame #7: 0x0000000001436e22 ton_node`_start + 226
  thread #3, name = 'log4rs refresh', stop reason = signal SIGBUS
    frame #0: 0x0000000802c292aa libc.so.7`__sys_nanosleep + 10
    frame #1: 0x0000000802abeefc libthr.so.3`___lldb_unnamed_symbol152$$libthr.so.3 + 44
    frame #2: 0x0000000001b39ca7 ton_node`std::sys_common::backtrace::__rust_begin_short_backtrace::hb2dedf59314682ea + 199
    frame #3: 0x0000000001b39ada ton_node`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf79e1d043270fb31 + 202
    frame #4: 0x0000000001cae91d ton_node`std::sys::unix::thread::Thread::new::thread_start::h36f97e85540097b5 + 45
    frame #5: 0x0000000802ab3859 libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 329
...

environment:

# uname -aKU
FreeBSD rnode28.itgold.io 13.0-RELEASE FreeBSD 13.0-RELEASE #3 releng/13.0-n244733-ea31abc261f: Fri Apr  9 06:43:18 UTC 2021     [email protected]:/usr/obj/usr/src_releng13/amd64.amd64/sys/GENERIC_TON  amd64 1300139 1300139

# pkg info zstd
zstd-1.5.0
Name           : zstd
Version        : 1.5.0

node version: 0.32.4

Wrong (hardcoded) path of part of db

You hardcoded part of database to /node_db

in validator_group.rs (164) let db_root = "node_db/catchains".to_string();
in validator_group.rs (222) ("node_db/candidates/{}", session_id.to_hex_string()))
in validator_manager.rs (258) new("node_db/last_rotation_block".to_string())

and may be somewhere else

It has to be corrected and placed to the db folder as all other parts of the db, according to "internal_db_path": in default_config.json file

Remove truncation of the body of bounced messages.

Problem:
Currently the body of bounced messages is truncated to 256 bits. In this case, the first 32 bits store the functionId.
This leads to the fact that it is impossible in the onBounce function to get sufficient information about the failed call.

When developing smart contracts, you have to save all the temporary necessary parameters in a mapping with the uint64 nonce key, make the first argument of the called function uint64 nonce, and then send another additional callback if successful for cleaning.
This approach cannot always be used and is not without drawbacks, as it can lead to an uncontrolled growth of temporary data and additional bugs.

Offer:
Do not truncate the body of bounced message and send all original data.

README

Hello
Could you add a short "how-to"

  • Build Node
  • Run Validator Node
  • Checking sync status
  • Health check of node

MESH

Abstract

This document specifies implementation of Mesh network aimed to allow connecting TVM-compatible networks on protocol level. The interchain relations mechanism will provide free flow of value and messages across several networks to ensure easy leverage of web3 applications deployed in different networks by smart contracts from each connected TVM-compatible network.

Motivation

There is a necessity to build a communication channel for smart contract interaction between independent TVM-based networks. New interchain communication mechanism must have the following traits:

  • High speed of transaction processing and high throughput capacity. The interchain communication channel must provide almost the same speed and throughput as the channel for external messages delivery;
  • Decentralization with no need for a trusted third party to validate interchain transactions;
  • Guarantee that one interchain message is delivered exactly once;
  • Asynchrony, i.e. outages of one network should not affect the operation of the others;
  • Ability to be flexibly configurable, i.e. it must have mechanisms for swift connection and disconnection of new networks and for workload orchestration.

Specifications

The proposed protocol-embedded mechanism of interchain communication (Mesh network) fulfils all of the abovementioned requirements. It will offer seamless smart contract message exchange as if contracts from different networks exchanged messages within a single network.

To achieve the outlined features, the concept of the proposed Mesh network ideologically relies on the currently existing workchain-to-worckchain interaction mechanism:

  • An outbound message to a smart contract deployed in workchain B appears in outbound message queue in workchain A;
  • Outbound messages from workchain A are transferred to the following master block 1;
  • Inbound messages appear in inbound message queue of workchain B its nodes receive master block 1;
  • Once the an inbound message is processed by the recipient smart contract in workchain B, the transaction is generated;
  • Transaction is recorded into the state, which is hashed and put into the following master block 2;
  • As workchain A nodes receive master block 2, the outbound message is considered delivered and gets deleted from the outbound message queue of workchain A.

Each network will have a list of connected external networks. Nodes of each network connected to Mesh will broadcast and receive masterchain block parts and masterchain state parts to other networks. If a queue of interchain outbound messages is not empty, nodes broadcast the block part of shardchain block containing the messages to the recipient external network nodes. The interchain messages are picked by collators of the recipient network from the inbound message queue. Message is processed by validators of the recipient external network.

Changes in Data Structures

Implementation of Mesh network requires making changes in existing data structures with adding new entities, reviewing the collation mechanism, and introducing a new message type.

Block data structure:

  • Outbound and inbound message dictionaries will be extended by interchain message type;
  • New dictionaries with interchain transactional data will be added to AccountBlock;
  • ValueFlow structure must will contain values of tokens sent to all of the external networks;
  • Blocks will include Merkle trees updates that will be broadcasted to the nodes of external networks.

Masterchain block structure:

  • ConfigParams will contain a list of connected external networks;
  • Masterchain block will include the information on the last masterchain blocks committed in every connected external network:
    • External masterchain block ID, logical time of the commitment, etc;
    • Sum of received tokens since the last block commitment;
  • Chain of shard block proofs will be added to ShardDescr. Every proof from the chain proves the immutability of the shard queue containing the messages to an external network.

Shardchain state:

  • Will include a separate queue of outbound messages for each connected external network.

Masterchain state:

  • ConfigParams will contain a list of connected external networks;
  • Masterchain block will include the information on the last masterchain blocks committed in every connected external network (the same data as in masterchain block structure).

A new message type that will be added to the network will be described further in the separate section.

Network

From the network perspective, interchain messaging in proposed realization does not differ from internal messaging. Consequently, the currently existing network layer structure will be used with addition of new requests.

Direct requests to external networks will be added to the network layer:

  • Request for a block part of the next master block;
  • Request for a block part with a block ID;
  • Request for shard state part stored in the nodes of the external network.

Virtual Machine

Virtual machine architecture will include new opcodes for working with messages from external networks or will redefine the currently existing opcodes to support interchain message processing.

Actions of message sending will be realized similarly to the current actions:

  • action_send_msg#0ec3c86d
  • action_set_code#ad4de08e

The virtual machine will also be reconfigured to work with interchain messages on its stack (searching and reading).

A method for reading the necessary parameters (gas price, message fee, and etc.) from an external network with its short ID will be added to the virtual machine.

Collation

Adjustments to the existing collation mechanism will preserve current guarantees for executing internal and external messages.

Execution of interchain messages is guaranteed to be performed only once in accordance with the logical time in their chain; the logical time of mesh participants will not be synchronized, i.e. every external network will have its own logical time.

No new rules for collator operations validation will be introduced. Collators will try to process as many messages as they can in the collation period restricted by the consensus time of one second. Messages will be processed according to their logical time and priority.

New message type

Сurrent TL-B message scheme does not allow adding new message types. Currently existing message types cannot be used for interchain messages.

Message format requires adding a new constructor of 1 byte in length. It will allow defining currently existing message types (will be backward compatible) and adding new ones

Changes in Network Configuration Parameters

ConfigParams will include information on external networks. Each network will be described by the following fields:

  • Zero state root and file hashes (zero state identifier);
  • Hardforks IDs;
  • Short ID of the network (used to locate an external network);
  • Connection status (Connected, Disconnected);
  • Native coin global ID;
  • Liquidity pool contract address;
  • Absolute values to define the limits for processing messages incoming from the network. These values can include (gas, message size, number of actions, etc.);
  • Emergency Guard public key;

and other service data.

Connecting a New External Network

As networks connected to Mesh have to exchange current state and last block parts with each other, all of the mesh participants must be synchronized with each other. The algorithm of connecting two external networks to each other is similar for both networks and must be performed synchronously:

  • Nodes of a network add reference to an external network GlobalConfig into their configurations. Thus, nodes from one network will be able to connect with the nodes from the external network;
  • The network configParams list of external networks is extended with the data about the new external network. At this point, networks still are in ‘not connected’ status;
  • Networks synchronize their states with each other: nodes of each network prepare block and state parts to broadcast to nodes of other external networks;
  • Once the states of both networks are synchronized, they are ready to exchange interchain messages.

External Network Disconnection

Disconnection of an external network is performed unilaterally via making changes to network ConfigParams, which means that the disconnected network cannot affect the process of its disconnection.

All the messages from the outbound message queue to the external network that is being disconnected must be processed.

Functionality of Emergency Guard will be implemented to request emergency interruption of interchain communication with a malfunctioning external network. The Emergency Guard will not be able to resume interchain communication on its own or totally disconnect an external network. In case the interchain communication has been interrupted by an Emergency Guard, interchain message exchange will be resumed by the same principle as in case of adding a new external network, i.e. via making changes in network ConfigParams.

Economic model

The economic model is developed to completely decouple the inter-network forwarding scheme from the economic issues of converting one token to another, as well as from the risks of a lack of liquidity, in which messages could become "stuck between networks".

Let's consider communication between networks A and B. Some smart contract in A wants to send tokens to B.

Liquidity pool and minting

The extra currency identifier corresponding to the native token of network B is written into the meta information about B in the global config of network A. This identifier should not be previously used. The system minter contract reads information about the identifiers of native tokens of other connected networks and uses it while minting (see below).

Conventionally, anyone can mint a certain number of tokens from network B in network A. To do this, you need to have tokens in network B and send them to the special liquidity pool. After this, in network A, send to the system minter contract a Merkle proof of transaction on the pool in network B. The minimum minted amount is limited by network B in the pull contract. It is expected that this amount is large enough to avoid overloading the mint system.

There can be exactly one liquidity pool contract for each external network.

The sum of all wrapped tokens B in network A always corresponds to the number of tokens on the pool in network B.

The minted tokens are then distributed as desired, according to any rules, exchange rates, and so on.

Messages delivery process

A smart contract in network A who wants to send a message to external network B must first ensure that he has network B tokens on his balance sheet (as an extra currency).

  1. a contract in network A generates a message to network B, and adds network B tokens.
  2. the sums of all tokens of all inter-network messages in all shard blocks committing to the master chain are subtracted from the global balance (actually burned). To do this, the master block does not need to enumerate all the messages - pre-calculated values are added to the value flow, it only needs to sum them up across all shards.
  3. when importing messages into network B, the amount that was burned at the previous step in network A is subtracted from the balance of the corresponding network A pool. In this case, the overall balance of network B does not change, since this amount will eventually be imported from messages. The balance in the pool is guaranteed to be sufficient, since in network A exactly as much mints is received as is received in the pool.

Bounce messages impossibility.

The proposed scheme is not symmetrical, it is one-sided. In order to send liquidity back from network B to network A, it needs to buy wrapped tokens of network A in network B. The purchase operation is external to the described transfer protocol and therefore cannot be performed automatically at the protocol level. This makes it impossible to automatically send bounce messages.

Network Fees

The network fees for interchain message delivery must be higher than internal fees, as conveyance of messages between different TVM-compatible networks is much more effortful for validators. The fees for interchain message processing are gathered in sending and receiving networks separately.

Rationale

Why protocol-embedded mechanism was chosen for connecting TVM-compatible networks?

Why was a protocol-embedded mechanism chosen for connecting TVM-compatible networks?
During our studies three possible approaches to building a channel for interchain communication were considered. These are: trusted bridge, trust-minimized oracle, and protocol-embedded mechanism (Mesh network). Two of the mentioned above do not fully meet the criteria enumerated in the Motivation paragraph.

A "trusted" bridge means that the bridge operates based on trust in a centralized or semi-centralized entity. In a trusted bridge, a central or trusted entity is responsible for maintaining the bridge and ensuring the security of the assets locked in the bridge's smart contracts. This entity is also responsible for minting and burning the wrapped tokens on the second blockchain. This means that the solution for interchain communication built upon a trusted bridge cannot meet the decentralization criterion.

A "trust-minimized oracle" refers to a mechanism for providing off-chain data to smart contracts in a decentralized and secure manner, while minimizing the need to trust any single entity. An oracle generates a proof that some action indeed occurred in network A and sends this proof to network B. A smart contract in network B checks the received proof and performs an action. The algorithm described above bears no necessity to trust any third party.

To check proofs, smart contracts from network B must have current public keys of the validator nodes from network A. The keys are also delivered by the oracles. The contract that emits a transaction to another network must implement the gathering of the necessary proofs, and the code of the receiving contract must include the full proof processing logic. Such additional functionality complicates smart contract source code. Along with the sophisticated oracle infrastructure, such an approach towards building an interchain communication channel also requires processing costly transactions of proof processing.

The channel implementing the logic described above will also rely on proxy smart contracts that will facilitate processing of the proofs. Such reliance may become a bottleneck and gravely affect the throughput capacity of the interchain communication channel.

What speed of interchain message delivery is expected?

Taking in account the mechanism outlined in this proposal, we can model the time breakdown of interchain communication with the following conditions:

  • Masterblocks are issued every 5 seconds;
  • Packet loss is minimal;
  • Both networks are not overloaded.

In such case, each step of the delivery of an interchain message from network A to network B will take on average:

  • Importing a message from network A, shardblock collation – 1 second;
  • Committing the shardblock to masterchain of network A – 2.5 seconds;
  • Committing the masterblock from network A in network B – 2.5 seconds;
    Issuing a shardblock in network B – 1 second;
  • Committing the shardblock into the masterchain of network B – 2.5 seconds.

So, the whole operation will take 9.5 seconds in the best scenario. Each step may require more time due to various causes. In the worst case, interchain message delivery may take dozens seconds, the upper boundary cannot be calculated precisely.

Why cannot workchains be used for external network communications?

All workchains of one given network share logical time (LT). Different networks, in turn, have different LT. Moreover, internal workchain messages have different priority and delivery guarantees in comparison to interchain messages.

Can Currency collection be used for non-native token transfers?

It is technically possible to use Currency collection structure for interchain transferring of non-native tokens, but it ha limitations:

  • Token IDs from Currency collections of different networks would have to be strictly bound to each other;
  • Liquidity pool contracts would require massive changes to adopt the of token transfers on the basis of Currency collection;
  • Currently, there is no network that uses Currency collection.

What would happen if an outage occurs in one of the external networks connected to Mesh?

If masterchain of network A does not receive information of its masterblocks commits to network B, it can indicate the following:

  • Network B lacks liquidity;
  • There are technical problems or protocol issues.
    Generation of outbound interchain messages in network A must be halted disregarding the causes of the network B outage. It will ensure that the interchain message queue does not grow excessively. To avoid throttling of interchain message sending, applications must monitor the health of the networks and send alerts in case of liquidity shortages or excessive growth of interchain message queues.

What would happen if an old contract receives an interchain message?

Old smart contracts would not be able to work with unknown (new interchain) message type.

Compile error

Compiling tokio-io-timeout v0.4.0
Compiling librocksdb-sys v6.11.4
Compiling h2 v0.2.7
error: failed to run custom build command for librocksdb-sys v6.11.4

Caused by:
process didn't exit successfully: /home/svt/rust-node/target/release/build/librocksdb-sys-da2569b647f841dc/build-script-build (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-.so', 'libclang.so.', 'libclang-.so.'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (invalid: [])"', /home/svt/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.54.0/src/lib.rs:1959:31
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

How do you determine failure status?

This is a failed state, how to determine according to the API

txid f0bdaf1d00bd9dd1ce558d633564e406db2c6f17b1c4d47741d25bed9388f00c

Get transaction

{
    "data": {
        "blockchain": {
            "transaction": {
                "id": "transaction/f0bdaf1d00bd9dd1ce558d633564e406db2c6f17b1c4d47741d25bed9388f00c",
                "end_status": 1,
                "end_status_name": "Active",
                "status": 3,
                "status_name": "Finalized",
                "account_addr": "0:f79e109e466e4068e6989577ffd9bfac76dc8f4aa1186082078b5c6fd1a04656",
                "tr_type_name": "Ordinary",
                "account": {
                    "address": "0:f79e109e466e4068e6989577ffd9bfac76dc8f4aa1186082078b5c6fd1a04656"
                },
                "bounce": null,
                "hash": "f0bdaf1d00bd9dd1ce558d633564e406db2c6f17b1c4d47741d25bed9388f00c",
                "credit": null,
                "balance_delta": "-24183132",
                "balance_delta_other": null,
                "total_fees": "0x1012206",
                "aborted": false,
                "lt": "0x1a52878ff901",
                "now": 1658894084,
                "in_msg": "9bf30b1a8f8ed8d4604f6ec5f46823646e88808d9462349b90d64b042a2a2b2a",
                "in_message": {
                    "bounce": null,
                    "msg_type_name": "ExtIn",
                    "src": "",
                    "dst": "0:f79e109e466e4068e6989577ffd9bfac76dc8f4aa1186082078b5c6fd1a04656",
                    "value": null,
                    "value_other": null,
                    "body": "te6ccgEBAwEAqwAB4e32X1wVtVkWH8dh6MXdWkITHZs3Yi2/qv7c7pZICdKPSPWvc35teIy9TU9fdUqrK5p/c+wqdSd68BuJ8GA9mgZqBTBrClU+qBlHIs58Ueqal9uMiQTcb1afB+o7+jebAEAAAGCPcrX3WLgtzsTHYLNgAQFjgA/zgVl6IDx+hGR/Z6kAMUSI0Ishtz2C0FVQPUsiQIO2YAAAAAAAAAAAAAAAAAy2ZNQCAAA=",
                    "code": null,
                    "code_hash": null,
                    "data": null,
                    "status_name": "Finalized"
                },
                "out_msgs": [
                    "fbdd596b9d59a692bd7db0e9b12c53d955e4b36f15160646366548386ad933bf",
                    "b45b92b599eec9ba8723bf8d7c9ff0d5634667b3225121a6701bf9a16afc0a1b"
                ],
                "out_messages": [
                    {
                        "bounce": null,
                        "bounced": null,
                        "msg_type_name": "ExtOut",
                        "code": null,
                        "src": "0:f79e109e466e4068e6989577ffd9bfac76dc8f4aa1186082078b5c6fd1a04656",
                        "dst": "",
                        "value": null,
                        "code_hash": null,
                        "status_name": "Finalized",
                        "value_other": null,
                        "body": "te6ccgEBAQEADgAAGJMdgs0AAAAAAAAAAA==",
                        "data": null
                    },
                    {
                        "bounce": true,
                        "bounced": false,
                        "msg_type_name": "Internal",
                        "code": null,
                        "src": "0:f79e109e466e4068e6989577ffd9bfac76dc8f4aa1186082078b5c6fd1a04656",
                        "dst": "0:7f9c0acbd101e3f42323fb3d48018a244684590db9ec1682aa81ea5912041db3",
                        "value": "6664998",
                        "code_hash": null,
                        "status_name": "Finalized",
                        "value_other": null,
                        "body": null,
                        "data": null
                    }
                ]
            }
        }
    }
}

Doesn't work after update

thread 'tokio-runtime-worker' panicked at 'Block handles seq_no must be written in ascending order!', /data/node/.cargo/git/checkouts/ton-labs-node-storage-1efe65d4a9df40ac/1db33bf/src/block_index_db.rs:203:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
ERROR src/sync.rs:37 [sync] 139963162424192: Error while downloading and applying package: panic
thread 'tokio-runtime-worker' panicked at 'Poisoned RwLock: "PoisonError { inner: .. }"', /data/node/.cargo/git/checkouts/ton-labs-node-storage-1efe65d4a9df40ac/1db33bf/src/block_index_db.rs:201:14

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.