VAIF Technical FAQ

From Veriblock Wiki
Revision as of 14:12, 8 January 2020 by FuzzyBot (talk | contribs) (Updating to match new version of source page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See: VAIF


Overview

There are a number of optimizations in progress to make adoption of PoP as simple and frictionless as possible.

The optimizations on this page can be merged into any VeriBlock-secured altchain when they become available, and will not require any additional hard-forking of the network to adopt.

Optimization Roadmap

Shrink PoP Tx/Block Size

Currently, altchain PoP transactions are large (5-30KB depending on how much VeriBlock and Bitcoin context the transaction contains). As a single transaction, this size is not an issue. However with potentially tens or hundreds of PoP transactions in a single altchain block (depending on game theory decisions made by each particular altchain), this size can quickly become an issue. Luckily, most PoP transactions contain mostly the same data (same VeriBlock PoP transactions, etc.), and "deduplication" of their contained data will shrink the combined size of multiple PoP transactions across multiple blocks significantly.

Native Library for Altchain Integration Service

Currently Altchain_Integration_Service runs as a separate service. This is a reusable Java service written once and called via gRPC in almost any language (C++, Java, Python, Golang, etc...)

Automation scripts and docker help abstract away the setup of this second service, but it is on the roadmap to rewrite it also as a native C++ library such that it can be directly embedded within the vBTC daemon. No separate service will be required.

Keeping ATV/VTB Context Updated

PoP works by creating, storing, and then applying ATV (Altchain-to-VeriBlock) and VTB (VeriBlock-to-Bitcoin) data structures. This context is necessary to validate altchain PoP transactions and perform fork resolution correctly. It requires an unbroken chain of PoP transactions for every keystone, which is to be expected in any MainNet environment.

However in TestNet, especially during development, there may not be regular PoP-ing. As a result, the TestNet environment may need to be re-bootstrapped often.

There are three ways that this will be simplified:

  1. Enable APM auto-mining - this keeps the context continually updated by keep submitting an altchain PoP transaction, as long as one APM is running on the network.
  2. Run APM updateContext command - this resets the context, and sends a corresponding transaction to the entire network to also update it and keep the network in sync.
  3. Use APM mock mining - stubs out the entire VBK and BTC testnets and creates mock ATV and VTBs. This allows a developer to run the entire system on their machine without needing to install or run all the moving parts upstream of the APM.