Integrating with Insolar
Upon the public network release, this chapter will be expanded to include the appropriate integration instructions.
Join or set up the Insolar network:
- :ref:`Connect to TestNet 1.1 <connecting_to_testnet>`. Participation in this network is permissioned, with participants invited by the Insolar Core Development Team based on their ability to fulfill the respective SLA.
- :ref:`Set up a network <setting_up_devnet>` locally for development and test purposes. The local setup is done on one computer with no particular system requirements, and the 'network nodes' are simply services listening on different ports.
Connecting to Test Network
To connect to Insolar TestNet 1.1:
- Skim through :ref:`known issues and limitations <issues_and_limitations>` and :ref:`system requirements <sys_requirements>`.
- :ref:`Set up and connect <connect_to_testnet>` a node.
Known Issues and Limitations
Issues below will be addressed in future releases.
On TestNet 1.1:
- Only computational (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 to the network.
- In the unlikely event of short-term storage (light material) nodes having to reconnect, multiple errors may occur for a few pulses.
- Only one long-term (heavy material) node and one pulsar are deployed. If either of the nodes is missing, the network will go down but, upon the node's restart, will recover.
- Storage node crash may lead to data loss.
- Under certain conditions, the node’s process (
insolarddaemon) may exit and its Docker container will restart it automatically. Insolar may also ask node holders for assistance with a manual restart.
- Nodes joining the network produce errors when other nodes are leaving the network.
Security & data consistency
- Smart contract validation is disabled. Therefore, any execution result returned by a virtual node is treated as verified.
- Distributed transactions are not yet implemented. This can lead to decorrelated object changes. For example, an interrupted 'money' transfer from one wallet to another decreases the source wallet's balance but leaves the target wallet's balance unchanged.
- Operations executed during pulse changes will be declined with the
Incorrect message pulseerror.
- Currently, all the data is stored and transferred unencrypted.
- All network messages are signed but signature checks are disabled.
- A simplistic rate limiter is implemented for light material nodes, so they reject incoming requests when the number of pending requests reaches a certain limit. This results in an exponential backoff on our benchmark tool -- the retry interval increases exponentially.
- The rate limiter does not consider the request's origin. So, when a user puts an excessive load on the network, other users may suffer.
- Only pre-built smart contracts are available. Custom contracts will be available on TestNet 2.0.
- All user wallets are created with a starting balance of 1,000,000 coins.
- Only one contract can be called via the node's API. All other methods (e.g., coin transfer) are called via the
Callmethod on a
Test Network System Requirements
Preferable system requirements for virtual nodes on TestNet 1.1 are as follows:
|40 cores||32 GB||256 GB SSD|
Insolar is meant to run on Linux, e.g., CentOS.
All servers wishing to join the Insolar test network must have public IP addresses.
Connecting to TestNet 1.1
To connect to the Insolar test network, do the following:
Install Docker and Docker Compose and run the Docker daemon.
Unpack the archive on your server. A good place is under the
Go to the unpacked directory, open the
docker-compose.ymlfile in a text editor, and insert your server's public IP address to the
keys.jsonfiles from Insolar. You can ask for them in our Telegram developer's chat.
Put the files to the
docker-compose up -d.
Enjoy being a part of the Insolar Network!
The Insolar's API is under development and not yet finalized. Please, await its first release.
In addition to the Insolar node, the Docker Compose starts Kibana and Grafana services to take care of :ref:`logging and monitoring <logs_and_monitor>`.
Insolar uses the following ports:
|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||Node's JSON-RPC API.|
|8080||TCP||Prometheus metrics endpoint.|
Setting Up Network Locally
To set up the network locally, do the following:
Since Insolar is written in Go, install its programming tools.
Make sure the
$GOPATHenvironment variable is set.
Download the Insolar package:
go get github.com/insolar/insolar
Go to the package directory:
Install dependencies and build binaries: simply run
Take a look at the
scripts/insolard/bootstrap_template.yamlfile. Here, you can find a list of nodes to be launched. In local setup, the 'nodes' are simply services listening on different ports.
To add more nodes to the 'network', uncomment some.
Run the launcher:
The launcher generates bootstrap data, starts the nodes and a pulse watcher, and logs events to
When the pulse watcher says
INSOLAR STATE: READY, the network is up and has achieved consensus. You can start running test scripts and benchmarks.
Also, you can manually bring up :ref:`logging and monitoring <logs_and_monitor>` by running
Logging and Monitoring
To see the node’s logs, open Kibana in a web browser (
http://<your_server_IP>:5601/) and click :guilabel:`Discover` in the menu.