Skip to content
Pre-release

@ita-sammann ita-sammann released this Apr 23, 2019 · 4105 commits to master since this release

Changelog

  • INS-2197: Fixed some race conditions that caused NPE in network transport
  • INS-2233: Fixed “failed to find jet (retry limit exceeded on client)” error
  • INS-2234: Fixed discovery node reconnection issue
  • INS-2245: Fixed “Error bootstrapping to address” issue when node is connecting
  • INS-2275: Normalized time format in logs
  • INS-2310: Added healthcheck handle to node API

Setup and run

To setup and start your node follow this instructions.


Assets 3
Pre-release

@ita-sammann ita-sammann released this Mar 26, 2019 · 4105 commits to master since this release

Changelog

  • INS-1958: Fixed metrics exporting to Prometheus
  • INS-2025: Added more debug logs
  • INS-2104: Added GetRequest message
  • INS-2146: Added Node’s static role to Prometheus metrics

Setup and run

To setup and start your node follow this instructions.


Assets 3
Pre-release

@ita-sammann ita-sammann released this Mar 14, 2019 · 4106 commits to master since this release

Changelog

INS-1196: Added Jet ID and Object ID fields to log output.
INS-1654: Made exporter more tolerant to errors. Exporter returns as much data as it can.
INS-1836: Added debug logs for “no message handler errors”.
INS-1837: Fixed “shouldn’t start queue processor with unknown pending state” error.
INS-1916: Added more verbose logs for node auth conflict case.

Testnet goals

  • Functional goals
    • Registration of new members and nodes
    • API to access member functions from external software
    • Transferral of funds between member accounts (no user interface, only API)
  • Non-functional goals
    • Prove scalability by number of nodes
    • Prove that we can run a network of 50 or more nodes
    • Archive at least 5k TX/s (in number of basic operations, not user operations) per 20 nodes, or over 10k TX/s for a 50 node network

Known issues and limitations

Node maintenance

  • For now, only computational (aka Virtual) nodes are available to external participants. Data storage is provided by Insolar nodes.
  • All discovery nodes are hosted by Insolar. Other nodes use them to reconnect the network.
  • In the unlikely event that short-term storage (aka Light Material) nodes having to reconnect, multiple errors may occur for a few pulses.
  • Only one long-term (aka Heavy Material) node is deployed for TestNet 1.1, and the network will stop if this node is missing. If this happens, the network will recover when this node restarts.
  • Storage nodes crashing may lead to data loss in this version.
  • Also, TestNet1 uses only one Pulsar Node and the network will also stop if this Pulsar Node goes down, resuming only when it comes back online.
  • Under certain conditions, the node’s process (insolard daemon) may exit and Docker container will restart it automatically. Insolar may also ask node holders for assistance with a manual restart.
  • Nodes joining the network will produce errors when there are other nodes leaving the network. This issue will be addressed in future releases.

Security & data consistency

  • Smart-contract validation is disabled in v1.1. Therefore, any execution result returned by a Virtual Node is treated as verified.
  • This version doesn’t have distributed transactions. This can lead to decorrelated object changes. For example, a “money” transfer from one wallet to another may be interrupted, so the balance of the source wallet decreases, but the balance of the target wallet will remain unchanged.
  • There is an issue with operations executed during Pulse changes. Such operations will be declined with the error: “Incorrect message pulse”. This issue will be addressed in future releases.
  • There is currently no data encryption. All data is stored and transferred unencrypted.
  • All network messages are signed, but signature checks are disabled.

Performance

  • There is a simplistic rate limiter implemented for Light Material Nodes and it will reject incoming requests when the number of pending requests reaches a certain limit. This results as an exponential backoff in our benchmark tool.
  • This rate limiter is unfair and doesn’t consider request origin. So when one user applies an excessive load to the network, other users will suffer as well.

Application level

  • Only pre-built contracts are available. Custom smart-contracts will be available in TestNet 2.0.
  • All user wallets are created with a starting balance of 1,000,000 coins.
  • There is only one contract that can be called from the node API. All other methods (like coin transfer) are called via the “Call” method on “member” object.

Setup and run

You must have Docker and Docker Compose installed to run the Insolar node.

  • Download insolar-node-v0.8.5.tar.gz
  • Unpack it on your server (to /opt/insolar for example).
  • Open docker-compose.yml with a text editor and insert the public IP address of your server in the INSOLARD_TRANSPORT_FIXED_ADDRESS field.
  • Put your cert.json and keys.json (these files should be provided to you by Insolar) to the configs directory.
  • Run docker-compose up -d

To stop the node, run docker-compose stop.

Ports used

Port Protocol Description
7900, 7901 TCP, UDP Nodes intercommunication. The node must be publicly available on these ports
8090 TCP Node - Pulsar communication. The node must be publicly available on this port
18181, 18182 TCP Communication between the main node daemon and the smart-contract executor daemon
19191 TCP JSON-RPC node API
8080 TCP Prometheus metrics endpoint

Test scenarios

Execute wallet smart contract, transfer coins

You can use an insolar command line tool to perform API requests. As each smart contract request has to be signed with the user key, this tool makes it simpler than using JSON-RPC API directly.

First, run an interactive shell inside the insolard container:

$ docker-compose exec insolard bash
$ cd /opt/bin

Then we can get info about network domains:

$ ./insolar -c get_info

Create two new users:

$ ./insolar -c create_member Satoshi > satoshi.json
$ ./insolar -c create_member Vitalik > vitalik.json

Now we have a JSON file with a key pair and ID for each user.

Let’s check the balances of their wallets:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>
$ ./insolar -c send_request -g vitalik.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>

Both users have an initial amount of 1,000,000,000 coins.

Now let’s transfer some coins:

$ cat vitalik.json

We need the caller field from the file. It is a user ID.

Transfer coins from one user to another:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"Transfer", "params":[12345,"<insert user ID from vitalik.json here>"]}
<Ctrl+D>

Now when we check balances again:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>
$ ./insolar -c send_request -g vitalik.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>

we see that one has been been debited and the other credited by the specific transfer amount.

Additional tools

You can run the benchmark tool to test network performance. This tool creates users with wallets and transfers money between them.

$ docker-compose exec insolard       \
    /opt/bin/benchmark               \
        -u http://insolard:19191/api \
        -k /etc/insolar/keys.json    \
        -c 20                        \
        -r 20

-u: Node API URL.
-k: Path to node’s key pair.
-c: Number of concurrent threads in which requests will be sent.
-r: Number of transfer requests that will be sent in each thread.

API requester tool runs a scenario in which it creates a number of users with wallets, then transfers some money between these users. On the first occasion, the script does the transfers sequentially, on the second time — concurrently.

$ docker-compose exec insolard       \
    /opt/bin/apirequester            \
        -u http://insolard:19191/api \
        -k /etc/insolar/keys.json

-u: Node API URL.
-k: Path to node’s key pair.

Logs and monitoring

Docker compose starts Kibana and Grafana services for logs and monitoring.
To see node’s logs open Kibana in a web browser: http://<your server’s IP>:5601/, click “Discover” in the menu.
To see monitoring dashboard open http://<your server’s IP>:3000/, log in to Grafana (login: admin, password: pass), click “Home” and there open “Insolar node” dashboard.

Assets 3
Pre-release

@ita-sammann ita-sammann released this Feb 28, 2019 · 4122 commits to master since this release

Testnet goals

  • Functional goals
    • Registration of new members and nodes
    • API to access member functions from external software
    • Transferral of funds between member accounts (no user interface, only API)
  • Non-functional goals
    • Prove scalability by number of nodes
    • Prove that we can run a network of 50 or more nodes
    • Archive at least 5k TX/s (in number of basic operations, not user operations) per 20 nodes, or over 10k TX/s for a 50 node network

Known issues and limitations

Node maintenance

  • For now, only computational (aka Virtual) nodes are available to external participants. Data storage is provided by Insolar nodes.
  • All discovery nodes are hosted by Insolar. Other nodes use them to reconnect the network.
  • In the unlikely event that short-term storage (aka Light Material) nodes having to reconnect, multiple errors may occur for a few pulses.
  • Only one long-term (aka Heavy Material) node is deployed for TestNet 1.1, and the network will stop if this node is missing. If this happens, the network will recover when this node restarts.
  • Storage nodes crashing may lead to data loss in this version.
  • Also, TestNet1 uses only one Pulsar Node and the network will also stop if this Pulsar Node goes down, resuming only when it comes back online.
  • Under certain conditions, the node’s process (insolard daemon) may exit and Docker container will restart it automatically. Insolar may also ask node holders for assistance with a manual restart.
  • Nodes joining the network will produce errors when there are other nodes leaving the network. This issue will be addressed in future releases.

Security & data consistency

  • Smart-contract validation is disabled in v1.1. Therefore, any execution result returned by a Virtual Node is treated as verified.
  • This version doesn’t have distributed transactions. This can lead to decorrelated object changes. For example, a “money” transfer from one wallet to another may be interrupted, so the balance of the source wallet decreases, but the balance of the target wallet will remain unchanged.
  • There is an issue with operations executed during Pulse changes. Such operations will be declined with the error: “Incorrect message pulse”. This issue will be addressed in future releases.
  • There is currently no data encryption. All data is stored and transferred unencrypted.
  • All network messages are signed, but signature checks are disabled.

Performance

  • There is a simplistic rate limiter implemented for Light Material Nodes and it will reject incoming requests when the number of pending requests reaches a certain limit. This results as an exponential backoff in our benchmark tool.
  • This rate limiter is unfair and doesn’t consider request origin. So when one user applies an excessive load to the network, other users will suffer as well.

Application level

  • Only pre-built contracts are available. Custom smart-contracts will be available in TestNet 2.0.
  • All user wallets are created with a starting balance of 1,000,000 coins.
  • There is only one contract that can be called from the node API. All other methods (like coin transfer) are called via the “Call” method on “member” object.

Setup and run

You must have Docker and Docker Compose installed to run the Insolar node.

  • Download insolar-node.tar.gz
  • Unpack it on your server (to /opt/insolar for example).
  • Open docker-compose.yml with a text editor and insert the public IP address of your server in the INSOLARD_TRANSPORT_FIXED_ADDRESS field.
  • Put your cert.json and keys.json (these files should be provided to you by Insolar) to the configs directory.
  • Run docker-compose up -d

To stop the node, run docker-compose stop.

Ports used

Port Protocol Description
7900, 7901 TCP, UDP Nodes intercommunication. The node must be publicly available on these ports
8090 TCP Node - Pulsar communication. The node must be publicly available on this port
18181, 18182 TCP Communication between the main node daemon and the smart-contract executor daemon
19191 TCP JSON-RPC node API
8080 TCP Prometheus metrics endpoint

Test scenarios

Execute wallet smart contract, transfer coins

You can use an insolar command line tool to perform API requests. As each smart contract request has to be signed with the user key, this tool makes it simpler than using JSON-RPC API directly.

First, run an interactive shell inside the insolard container:

$ docker-compose exec insolard bash
$ cd /opt/bin

Then we can get info about network domains:

$ ./insolar -c get_info

Create two new users:

$ ./insolar -c create_member Satoshi > satoshi.json
$ ./insolar -c create_member Vitalik > vitalik.json

Now we have a JSON file with a key pair and ID for each user.

Let’s check the balances of their wallets:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>
$ ./insolar -c send_request -g vitalik.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>

Both users have an initial amount of 1,000,000,000 coins.

Now let’s transfer some coins:

$ cat vitalik.json

We need the caller field from the file. It is a user ID.

Transfer coins from one user to another:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"Transfer", "params":[12345,"<insert user ID from vitalik.json here>"]}
<Ctrl+D>

Now when we check balances again:

$ ./insolar -c send_request -g satoshi.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>
$ ./insolar -c send_request -g vitalik.json -p -
{"method":"GetMyBalance"}
<Ctrl+D>

we see that one has been been debited and the other credited by the specific transfer amount.

Additional tools

You can run the benchmark tool to test network performance. This tool creates users with wallets and transfers money between them.

$ docker-compose exec insolard       \
    /opt/bin/benchmark               \
        -u http://insolard:19191/api \
        -k /etc/insolar/keys.json    \
        -c 20                        \
        -r 20

-u: Node API URL.
-k: Path to node’s key pair.
-c: Number of concurrent threads in which requests will be sent.
-r: Number of transfer requests that will be sent in each thread.

API requester tool runs a scenario in which it creates a number of users with wallets, then transfers some money between these users. On the first occasion, the script does the transfers sequentially, on the second time — concurrently.

$ docker-compose exec insolard       \
    /opt/bin/apirequester            \
        -u http://insolard:19191/api \
        -k /etc/insolar/keys.json

-u: Node API URL.
-k: Path to node’s key pair.

Logs and monitoring

Docker compose starts Kibana and Grafana services for logs and monitoring.
To see node’s logs open Kibana in a web browser: http://<your server’s IP>:5601/, click “Discover” in menu.
To see monitoring dashboard open http://<your server’s IP>:3000/, log in to Grafana (login: admin, password: pass), click “Home” and there open “Insolar node” dashboard.

Assets 3
You can’t perform that action at this time.