The following information provides a list of terminology for ARKLauncher that you may need to familiarize yourself with. The provided descriptions outline the various parameters contained within ARKLauncher and will guide you in determining the optimal setup for your unique configuration.
The parameters listed within this section outline the general aspects you will need to decide upon when launching your blockchain. In short, you will need to consider your blockchain logo, name, ticker symbol and symbol as well as the address prefixes for the different types of networks that exist.
This is the logo that ARKLauncher will use internally to designate your blockchain. Note that this logo is not visible to the outside world and only applies to the internal user interface of ARKLauncher.
This is the name you want to give to your cryptoasset and blockchain that ARKLauncher will generate. Keep in mind that the public can see this name, so ensure that your chosen name is unique and something you want associated with your project.
This is a kind of shorthand designator for your cryptoasset. As such, it is typically used by exchanges when implementing your token for trading and will serve as a convenient way for users to refer to your token in various online environments.
This is the symbol you would like to use as a kind of text-based logo or marker for your cryptoasset. This symbol may appear in wallets, on exchanges or any other website or application that displays your token and/or token balances to end users. Take the dollar sign (
$) for instance - when someone references something in US dollars, they use the
$ symbol (so for example, five dollars and fourteen cents will appear as
An address prefix is an alphabetical value or letter that precedes your network addresses. In the case of the ARK Network, this value is the letter ‘A.’ Each address therefore starts with the letter ‘A’ on the ARK Network. However, the ARK Development Network uses the letter ‘D.’ This means all addresses on the ARK Devnet starts with the letter ‘D.’
A Production network generally functions as your live network that supports your native cryptoasset. This is what many would consider or refer to as your ‘Main’ network (or
mainnet). As such, this network is for real-world activity and used by various stakeholders across the globe.
A Development network (or
devnet) is typically created to provide your development team with a private version of the network to build and develop on when creating new features. For this reason, this network is exclusively for members of your core team and is usually not open to the general public.
A Test network (or
testnet) is used to publicly test your network and any updates to the code. A typical development cycle would internally test an update on the Development network and then push the update to the Test network for public testing to get more feedback and a more reliable real world testing phase. This network is usually open to the public and users are encouraged to help test updates to this network before they are released to the Production network.
Please review the Customize - General page for more information regarding the aforementioned parameters.
This section outlines various parameters that you will need to consider when creating your blockchain. This encompasses the number of forgers, block time (seconds), maximum transactions per block, maximum payload length by block, total initial supply and so forth. It also describes various parameters related to ports and your database.
Number of Forgers
The number of forgers on your network determines how many Validators (or Delegates) may enter an active forging position at any given time. Validators confirm blocks on your network and directly participate in consensus. The number of forgers directly affects the security of your network as well as the time required to validate each new block.
- A larger number of Validators results in a longer period of time in which to reach consensus, but
- A smaller number tends to centralize your network, thus (in the opinion of some critics) reducing overall security.
We highly recommend that you use a prime number for your Number of Forgers to avoid contentious ties among Validators on the network.
This refers to the amount of time it takes for each new block to complete. This time is calculated in seconds and will require adjusting in relation to the number of Validators on the network. In the case of ARK, 51 Delegates participate in consensus, thus allowing for an 8 second block time. With this in mind, in a network with 101 Validators, we recommend increasing the block time to no less than 12 seconds.
These values will require some testing - when you deploy a blockchain with a custom Number of Forgers and Block Time, we recommend you first test performance on your Development or Test network to ensure the network performs as anticipated.
Max Transactions Per Block
This determines the maximum number of transactions a single block may contain. Certain limitations exist in terms of how much data a block is able to hold - with this in mind, the number of forgers and block time also play a role in determing what constitutes a reasonable amount of data.
- Increasing Max Transactions Per Block permits a block to include more transactions, but this will drastically increase the overall size of your blockchain over time.
- Decreasing Max Transactions Per Block allows for the maintenance of a blockchain that is smaller in size, therefore reducing the minimum hardware required to run a full node. However, the trade-off is queued user transactions may build up, thus resulting in increased fees due to network congestion. Furthermore, this may lead to a longer period of time required in order to properly confirm transactions.
The ARK Network currently utilizes 150 Max Transactions Per Block.
Max Payload Length by Block
Similar to Max Transactions Per Block, the Max Payload Length by Block can also significantly impact the performance of your blockchain. In order to understand this parameter, it is important to understand the different types of transactions available on the network, particularly ‘multi-payments:’
- Multi-payment transactions can contain numerous transactions worth of information, but in spite of this, the network only considers it a single transaction. As a result, it is crucial that we impose a constraint on the total payload length we allow in a given block. Without this value, someone could theoretically send 150 multi-payment transactions at once and potentially overwhelm the network.
- The network will always check the Max Payload Length by Block before determining whether you have reached the Max Transactions Per Block. This allows for checks and balances on the amount of data included in each block and ensures the network can maintain optimal performance at all times.
This determines how many tokens the Genesis block of your network will generate. ARKLauncher will create and subsequently deposit these tokens into a Genesis wallet (which you can access using the generated passphrase) during the blockchain deployment process.
Keep in mind that the Total Initial Supply will also account for the 8 digits after the decimal point. If you want to create a Total Initial Supply of 125 Million tokens, you will need to input 12500000000000000. This number equates to 125,000,000.00000000 (125 million, then a decimal point followed by 8 trailing zeros).
Reward Height Start
This parameter determines at which block number (or block height) your network will begin generating forging rewards for Validators. This is important in that it provides you with time between the initial launch of the network and the onset of rewards to ensure public Validators can actively work to secure the network going forward.
We recommend the default of 75,600 for most users. This should provide sufficient time for your network to acquire Validators before forging rewards come into effect on the network.
Reward Per Block
This determines how many tokens each new block generates as a reward for Validators. The Reward Height Start value determines at which point the network begins minting new tokens, and it will mint a given number of tokens in each block based on your Reward Per Block. Any newly minted tokens will transfer to the Validators on your network as a reward for the resources they commit towards ensuring the security of the network.
The Reward Per Block also includes the last 8 trailing zeroes after the decimal point. As an example, a reward of 2 tokens per block would require a value of 200000000, which effectively equates to 2.00000000. However, the decimal will not appear in the ARKLauncher configuration file.
Vendor Field Length (Bytes)
This parameter determines the amount of data that users can place in the Vendor Field of a transaction. The Vendor Field is a custom data field that allows for the inclusion of additional information in a transaction. The size of the Vendor Field Length is denoted in bytes and can significantly impact performance if the value is set too high.
We recommend a value between 64 and 255 for the Vendor Field Length.
Wallet Input Format (Number)
The Wallet Input Format (or WIF) is a highly complex value that we do not recommend most users alter. This parameter applies to more advanced users who understand the underlying code. To this end, we recommend a value of ‘1’ for most users.
For more information on WIF, review the article located here .
Users may customize the ports used by their blockchain within ARKLauncher. These ports determine how your network will communicate among peers.
We recommend the default settings for most users.
If you consider yourself an advanced user and wish to alter these settings, it is possible to customize the following ports in ARKLauncher:
- Public API
- Monitor, and
A custom database hosted by nodes on your network will store the history of your blockchain.
The majority of users should not need to customize this data, and so we recommend using the default settings.
If you consider yourself an advanced user, it is possible to customize the following parameters in ARKLauncher:
- Port, and
Please review the Customize - Network page for more information regarding the aforementioned parameters.
Your blockchain may make use of either Static or Dynamic network fees. To change the type of fees you wish to use, simply click the Enable toggle for Dynamic Fees.
For more information on Network Fees and the manner in which calculations for Dynamic Fees occur, please see ARK Improvement Proposal (AIP) 16 (this is the live implementation at this time).
Please review the Customize - Fees page for more information regarding the aforementioned parameters.