Introduction

Velocity is a tertiary blockchain constraint/consensus system designed to ensure stringent block checks and parameter enforcement. This system was designed as a modular/scalable framework and over the years of its use has been expanded to include other check types along with having been completely overhauled to include advanced block vetting found nowhere else. Showing its usefuleness now in several different blockchain implementations Velocity is looking to be a promising blockchain feature. Example implementations can be found in DigitalNote [XDN], Espers [ESP], INSaNe [INSN], Rubix [RBX], Nucleon [NEON], PupaCoin [PPCN], FrogCoin [FROG], Konjungate [KONJ], InfoCoin [INFO], BreadCoin [BREAD], ZalemCoin [ZLM] and Endox [EDX] as of the writing of this document.

Importance

The key importance of Velocity is to constrain the chain with the parameters already defined within the code as apposed to having aspects such as block spacing, detailed block data processing, and other properties be subverted simply if a user/developer is clever about how they organize the block data or how they malform it. This is very important in several ways as everything from sudden increase in hashrate, invalid network fees, possible invalid ballance issues while sending transactions and other attacks/exploits. These mentioned issues are still a vulnerability despite the best retarget systems out there being implemented to control block spacing and though many portions of Bitcoin and similar projects' blockchains are checked they are done so in a lackluster manner and are still suseptable to an attack wether it be temporary or a catastrophic generation of coins that causes users of the network grief and major loss. This is resolved by the Velocity system stepping in as a "tripple check". Even after a block during generation has seemingly met all requirements and is then produced it is now no longer immidiately accepted. Instead it is checked again for inconsistancies and possible other exploits and even compare against other peer's block data.

Technical Aspects

Most notably users will initially see rejected blocks during the mining or staking phase (or both depending on coin properties). Despite the tendency to assume that there is something wrong with the chain as it is rejecting blocks this is in fact a completely normal and a welcomed operation. Rapid block times, incorrect fees, insufficient ballance, faked/altered timestamps, altered inputs/outpus and other issues can be manipulated by a talented programmer with malicous intent. To guard from these kinds of situations Velocity first checks the generated block for proper spacing, if the block was generated too quickly it has then not met one of the main parameters for the chain and is promptly rejected, staving off possilbe attacks and any kind of sudden increase in hashrate. Additionally to verifying block spacing Velocity also checks both block timestamp and block transaction timestamps against previously indexed values in order to verify the legitimacy of the timestamp within a block. This is done at least a couple blocks or more deep to ensure timestamp attacks are negated. Next the system verifies that previously the client that sent a transaction (if it sent one in the previous block) was in fact a valid transaction by comparing previous ballance vs current ballance along with fees paid vs minimum fee required to pay. If any of these parameters are not met (mind you these are standard chain parameters that should always be stringently enforced) then the block is again rejected despite being generated successfully. Thus this system secures the chain, making it more stable, predictable, and overall reliable. With Velocity there's confidence that the blocks being accepted are indeed blocks that are proper.

Limitations

Currently the biggest shortcoming is that this feature is still a prototype system and as such doesn't intuitively integrate into every blockchain flawlessly. Some can experience issues such as minimum spaced blocks with either min-diff or near min-diff being used which is not an optimal operation of any sort. Hybrid blockchains require a more intuitive difficulty retarget approach to reduce rejected blocks and cause the system to properly generate blocks so that Velocity becomes not a life support system but merely a security check to a stable and properly operating chain. Users of a Velocity implemented chains may also note that several blockchains have now been implemented with this feature, however the potential issues will NOT be apparent in them because they are implemented with VRX difficulty retargeting which pairs with Velocity's constraints. This will not have the same issues listed above, in this case they will see only the benefits of Velocity running as a security check merely stabilizing the blockchain further and making it more robust.

Improvements

In July of 2021 several Bitcoin [BTC] based altcoins were attacked with what has now been nicknamed the "Monte Spoof Attack" as a nod to a typical method used by scammers known as a "Three Card Monte". The Monte Spoof Attack is a completely new method of exploit created that does not require the same sort of power as a 51% attack, timewarp, or other attack methods. Instead to carry out the exploit the attacker simply needs to be able to create the next block for the blockchain and submit it in time to have at least just one block accepted. In simpler terms someone with simply 10-20% of a chance of creating the next block in time for the chain to accept it, which can execute this attack. Once the attacker submits the block they exploit the fact that Bitcoin [BTC] assumes that a peer will only submit transaction data in the block it created by using transactions from the main network memory pool (what users have been sending to each other). Trusting a peer this way allowed for attackers create large amounts of coins by injecting custom formed transactions directly into the block they created without relaying it across the network, this completely bypasses the security that had been deemed unbreakable for the past many years. To combat this Velocity was immediately overhauled within the first week of the new exploit being found. Velocity now features extensive block input/output checks, blockchain supply checks and many more that ensure that nothing is ever overlooked during any part of the block acceptance phase regardless of what the networks sees or thinks would be there. Again in 2022 Velocity was integrated with a new feature built known as Demi-Nodes. This advanced networking system relies on Velocity as it streams blocks through the security checks when making decisions on peer validity and what blocks the network has compared to what a user has stored or created locally. Due to this block sync times are faster and overall network health is much stronger.

Future

This system can be expanded to eventually include more checks, more verification and a even more stringent implementation that may adapt to any kind of features that are added or removed. This makes the system very adaptable and less of a hassle to work with as it can grow with the needs of a blockchain project. As it becomes more refined and mature so will this new security feature called Velocity.