Sample CustomNetwork

VeChain already has two very smooth running blockchains: The mainnet and the testnet. Obviously, testing in mainnet is pricy, because you actually need to buy VTHOR. Testing in testnet is a valid option but the testnet currently has a 16 Million GAS limit per block. And we want to go beyond that. FAR beyond!

Tweaking the client!

I did some changes in the source code to enable me to test faster. You can look through my GIT repo and clone it yourself but I will also walk you through the changes.

  1. TX Pool Size: I change the maximum size of transactions in the TX-Pool from 64KB to 256KB. This is to be able to send bigger transactions.
  2. BodyRequest Size: I changed the maximum site of the Requestbody from 200KB to 1MB. Also to send bigger transactions….
  3. TX Pool Amount and duration: On the normal mainnet, a unique sender could “only” have 16 transactions in the TX Pool. This is plenty for real users, even for big players. But I needed more, so I increased that amount from 16 to 64 and the maximal age of a transaction from 20 to 80 minutes.

Thats it. Although there are more changes in the GIT Repo, they are not related to the features of the chain.

How to setup a custom network?

To be able to run a custom VeChain network, you need to set up at least two (software) nodes and start the Thor client with some special settings. VeChain already described the process here: CustomNets

So let’s start with the server: We need at least two server running the Thor client and at least one of them has to sign blocks. So I set up two “Debian 9” VPS at my favorite hoster Vultr. The VPS are from the 10$ plan with 1 CPU, 2GB RAM and 25GB SSD. Keep those numbers in mind!

Now we need to install the Vechain Thor Client. You can do this by following this script (tested with Debian 9). The last line in the script will pull the config file for my custom network. This config sets the GAS Limit to 500 million and the relation of gas to VTHOR from 1.000 to 10.000, so a transaction only costs 2,1 VTHOR instead of 21. This can do some BIG blocks. This also sets the Authority Nodes to addresses which private keys I own. To be able to sign blocks, at least one Node needs to have a private key put in /home/thor-node/.org.vechain.thor/master.key.

**WARNING: **This script will install a modified Vechain Client, not approved by VeChain. Only use the for testing!

Also: This network and the coins in it are not worth any money.

When done installing the two machines, you can fire up your own VeChain network by starting the client like this.

/home/thor-node/go/src/VeChain/thor/bin/thor — network /home/thor-node/go/src/VeChain/thor/genesis/MiRei.json — api-addr

Connect to the CustomNetwork

Now that I have my own network running, I need to connect and interact with it; and I want other people to be able to connect (and interact) with it, too. So I set up a nice hostname: The play API is of course not very fancy to use but VeChain has already released Sync and I can add CustomNetworks to Sync! All I need to do is to click on the green “Main”, say “Add Node” and enter the settings as shown below. You can do that too ;) [block:image] { “images”: [ { “image”: [ “”, “24.1.png”, 960, 730, “#f0f0f1” ], “caption”: “Adding a CustomNetwork to Sync” } ] } [/block] Browsing the CustomNetwork

Sync is already a BlockExplorer and it is an absolute charm to use it on my own network. As you can see below, my very own genesis block on a VeChain CustomNetwork! [block:image] { “images”: [ { “image”: [ “”, “20200114-1.png”, 1416, 840, “#eceded” ], “caption”: “Genesis Block of the BFC CustomNetwork” } ] } [/block] So, a private Chain with nothing in it. Boring!!!! I need to change that; and change it really good! So I wrote myself a little something. As you can see on the Genesis Config File, there are six addresses in total containing VET and VTHOR. We will focus on the last five (yea, I used some GPU power to get these addresses :D ):

  • 0x000000007b5001b903c318d7c3ea08c2122f3cc5
  • 0x00000000dd4c260a48dd4cee9ce0ed886b2c885a
  • 0x0000000026734229f89cf4510a6c032af9aa44b3
  • 0x000000002f119af6efe941a0c82dfa2d0b2c29e7
  • 0x000000005dff479885f529f3a7e0a7029e83f74e

To be able to have more sender/recipients, I wrote a basic “Wallet Management and Distribution System” and added 20.000 Adresses to it. And with a maximum GAS Limit of 500.000.000 per Block I can distribute VET/VTHO to those addresses really quick.

In the video below I send 800.000 VET and 20.000 VTHOR to 20.000 addresses each in a total of 40 transactions. And I did that again for VTHOR from another wallet, so every address has 800.000 VET and at least 40.000 VTHOR. [block:embed] { “html”: “<iframe class=”embedly-embed” src=”//” width=”640” height=”480” scrolling=”no” frameborder=”0” allow=”autoplay; fullscreen” allowfullscreen=”true”>”, “url”: “”, “title”: “VeChain BFC CustomNetwork - Distributing VET to 1000 Addresses in one transaction”, “favicon”: “”, “image”: “” } [/block] As you can see in the video, I have

  • created transactions containing 1000 clauses each.
  • created blocks consuming 96M gas and including 6 transactions with a total of 6000 clauses
  • distributed a total of 16 Billion VET to 20.000 addresses in four blocks and that took 40 seconds
  • done all this with two VPS with 1 CPU and 2 GB of RAM.
  • NOT changed any mechanic of the chain to work any different than the mainnet. The VeChain Thor mainnet can do that!

The tests in this part are purely to max out the technology. To give you a perspective about whats going on and why these numbers are important for the technology but not so much for the actual mainnet, I need to explain a feature unique to Vechain. [block:image] { “images”: [ { “image”: [] } ] } [/block] What are Multi-Task-Transactions?

VeChain has a build-in technology called Multi-Task-Transactions or MTT. With MTT a transaction can contain multiple clauses. You can get an idea of that if you imagine a transaction as an Excel-file. In Ethereum, the “father” of VeChain, the Excel-file itself contains the “sender” and additionally contains exactly one row. In this row are the colums “to”, “amount” and “data” (simplyfied). In VeChain the same Excel-file can contain multiple rows. Like thousands of them.

Now imagine your Ethereum-boss gives you a task to put 5.000 sets of data from the same “sender” into 5.000 Excel-files. You have to create the file, put in the data, save the file to the appropriate place and repeat for 4.999 times. If your VeChain-boss gives you that same task, you don’t have the overhead of doing ”create the file” and “save the file” all over again. You create one Excel-file, put in the 5.000 sets of data and save it. Boom. Done.

That’s the same thing I am doing here. I am creating incredible big transactions with unrealistic high amounts of clauses, becauses I only have to create one transaction with 5.000 clauses instead of 5.000 transactions with 1 clause each. My litte Ryzen 5 can do those small amounts of big transactions but for a more natural reflection of the actual usage of the mainnet, much more CPU-power is needed (maybe in part 3 ;) ).

So it is important to know the difference between TPS (Transactions Per Second) and CPS (Clauses Per Second). Although CPS can reflect natural usage, the ratio between transactions and clauses will never be like it is in my tests. TPS and CPS is also the difference between the blue and the yellow chart .

[block:image] { “images”: [ { “image”: [ “”, “20200113-1.png”, 769, 171, “#fbfbfa” ], “caption”: “VeChain Transactions and Clauses” } ] } [/block] Infrastructure upgrade

The tests above were done using two nodes with 1 CPU and 2 GB RAM. For the testing in this part I had to upgrade my nodes. The load of the chain forced me to upgrade to 4 CPUs and 8 GB RAM. The monthly infrastructure costs went up from 20$ to 80$.

The Blockexplorer

To pull statistics of my tests I need the results of transactions and clauses in each block. A few months ago, I wrote a blockexplorer for myself that imports the chain into MySQL. That way I can do easy SQL queries over the chain. That came in handy now.

Show the numbers already!

Okay, here we go. In my tests I was able to get astonishing results. You can check them yourself at

In the chart below I took statistics of a blockrange to not overload the chart. The complete information can also be downloaded. I was able to push around 30–40 transactions with 25.000 clauses in each block all the time. The block algorhythem did not allow more at the time. You can see in the csv file that there were some drops because of chaincrashes (due to limited resources) or restart of the clause-generating-script. [block:image] { “images”: [ { “image”: [ “”, “24.4.png”, 1600, 760, “#f9fafa” ], “caption”: “Transactions and Clauses of my BFC Testchain” } ] } [/block] If you open the links below in Sync connected to you can see them directly.

Highest transactions in one block: 64 transactions were put in Block 337. This is nothing special. This happened on the mainnet already.

Biggest Block: Block 325 is 867.465 Byte (867KB) big. Remember that Bitcoin does 1MB blocks every 10 minutes.

Highest amount of gas used in a block: Block 325 has also burned the most gas with 431.087.680 (431M) in total. An equivalent of 431.087 VTHO on mainnet.

Highest amount of clauses in one block: Again block 325. It had 26.920 Clauses in it.

Highest amount of clauses in a transactions: The highest amount I tested was 5.000 clauses in a single transaction. This happened the first time at block 19.

Average CPS over one hour: Over 360 blocks (from block 188 to block 548) the average Clauses Per Second were 2.370,9 CPS! Scaled up to one day (86.400 seconds) this results in a theoretically amount of unbelievable 204 million clauses per day, done with two VPS and 2x4 CPUs.

Conclusion Although I am sure that these are not the maximum values of the chain, I am very confident, that TPS or CPS will not be a problem in the near future. Also including the clean source code and the Vechain Tech Deep Dive Series on Youtube it makes me even more confident that VeChain will deliver high-quality solutions; down from the smallest technological aspect up to complete BaaS environments (Blockchain-as-a-Service).