Vidnix Whitepaper
Vidnix is a decentralized node streaming platform benefiting both the P2P and enterprise level, for peers its a social media platform where everyone gets paid for uploading, curating and even watching the content posted on Vidnix web & mobile applications, nodes on Vidnix share storage with each other it allows any node to send and receive a video into a network. Vidnix itself stores only the source codes and smart node contracts formed between parties, defining the terms of their arrangement, for enterprise Vidnix supports source codes based on all algorithm, Vidnix allots a dedicated amount of hosts storage clients required for block confirmations of their tokens. By downloading the application, the broadcaster (also known as a host) agrees to let the application mature blocks and confirm transactions for the client, and to periodically submit proof of engagement until the contract expires. The host is compensated for every proof they submit, all proofs are publicly verifiable (and are publicly available in the blockchain), Network consensus is used to automatically enforce streaming contracts. Importantly, this means that clients do not need to personally verify streaming proofs; they can simply upload their file and let the network do the rest, storing data on a single untrusted host guarantees little in the way of availability, bandwidth, or general quality of service. Instead, Vidnix stores data redundantly across multiple hosts. In particular, the use of erasure codes can enable high availability without excessive redundancy.
Vidnix uses a scripting system to enable a range of transaction types, such as pay-to-public-key- hash and pay-to-script-hash similar to Bitcoin script, it extends transactions to enable the creation and enforcement of client contracts. The extensions used to accomplish this are: node contracts, engagement proofs, and contract updates. Contracts declare the intention of a host to work as a medium of maturing blocks on client’s behalf by downloading the application. They define the regularity with which a host must submit engagement proofs. Once established, contracts can be modified later via contract updates.
- Version: Protocol version no. 60014
- Arbitrary data distribution: Arbitrary data distribution of client nodes (see ADD)
- Proof of engagement: Rewards awarded on basis of engagement (see proof of engagement)
- Inputs & Outputs: Incoming and outgoing (see inputs & outputs)
- Node contract: See node contract (see node contracts)
- Signatures: Signatures from each input
Each transaction has an arbitrary data field which is used to carry node unique identifiers corresponding to the client node contract conditions. Nodes will be required to store the arbitrary data if it is signed by any signature in the transaction. Nodes will initially accept up to 165 KB of arbitrary data per block. This arbitrary data provides hosts and clients with a decentralized way to organize themselves. It can be used to create a decentralized file tracker. Arbitrary data could also be used to implement other types of soft forks. This would be done by creating an “anyone-can-spend” output but with restrictions specified in the arbitrary data. Miners that understand the restrictions can block any transaction that spends the output without satisfying the necessary stipulations. Naive nodes will stay synchronized without needing to be able to parse the arbitrary data.
Engagement proof transactions are periodically submitted in order to fulfil file contracts. Each engagement proof targets a specific node contract. An engagement proof does not need to have any inputs or outputs; only a con- tract ID and the proof data are required. Hosts prove their engagement by providing a segment of the original file and a list of hashes from the file’s Merkle tree. This information is sufficient to prove that the segment came from the original file. Because proofs are submitted to the blockchain, anyone can verify their validity or invalidity. Each storage proof uses a randomly selected segment. If the host is consistently able to demonstrate indulgence for specific time span of a random content segment, then they are very likely to achieve set conditions as per individual contract for minimum nodes clearance required to achieve a reward.
Each output comprises a defined volume of coins and it has an associated identifier unique to its properties, which is derived from the transaction that the output has appeared in. The ID of output in a transaction is defined as: H(t||“output”||i) where H is a cryptographic hashing function, and “output” is a string literal. The block reward and engagement reward have special output IDs. Every output must comes post an input entry, so an input is simply an output ID. Inputs and outputs are also paired with a set of spend conditions. All inputs carry the spend conditions by default, while outputs contain their Merkle root hash [2]. An output comprises a volume of coins. Spend conditions are properties that must be met before coins are “unlocked” and can be spent. The spend conditions include a time lock and a set of public keys, and the number of signatures required. An output cannot be spent until the time lock has expired and enough of the specified keys have added their signature. The spend conditions are hashed into a Merkle tree, using the time lock, the number of signatures required, and the public keys as leaves. The root hash of this tree is used as the address to which the coins are sent. In order to spend the coins, the spend conditions associated with the address hash must be produced. The use of a Merkle tree allows parties to selectively reveal information in the spend conditions. For example, the time lock can be revealed without revealing the number of public keys or the number of signatures required. It should be noted that the time lock and number of signatures have low entropy, making their hashes vulnerable to brute-forcing. This could be resolved by adding a random nonce to these fields, increasing their entropy at the cost of space efficiency.
A Node contract is an agreement between a web/mobile application host and vidnix client. At the core of a file a node contract is in the file’s Merkle root hash. To construct this hash, the file is split into segments of constant size to nest client’s node scripts and hashed into a Merkle tree. The root hash, along with the total size of the file, can be used to verify engagement proofs. Node contracts also specify engagement duration, challenge frequency, and engagement rewards parameters, as per the contract the client and reward its own tokens or vidnix (VDX) coins including the reward for a valid proof, the reward for an invalid or missing proof, and the maximum number of proofs that can be missed. The challenge frequency specifies how often an engagement proof must be submitted, and creates discrete challenge windows during which a host must submit activity proofs per engagement. Submitting a valid proof during the challenge window triggers an automatic payment to the “valid proof” address (presumably the host). If, at the end of the challenge window, no valid proof has been submitted, coins are instead sent to an unspendable address in order to disincentivize DoS attacks.
Input in a transaction has to be signed, a cryptographic signature is paired with an input ID, a time lock, and a set of marker indicating which parts of the transaction have been signed. The input ID indicates which input the signature is being applied to, the time lock specifies when the signature becomes valid and any subset of fields in the transaction can be signed, with the exception of the signature itself, there is also a marker to indicate that the whole transaction should be signed, except for the signatures. The actual data being signed, then, is a string of the time lock, input ID, markers, and marked field, each signature in the transaction must be valid for the transaction to be accepted.
Vidnix offers an ecosystem that facilitates decentralized node clearance to support POS based coins/tokens. Network user the host can use the arbitrary data field to announce themselves to the network and connect to the client nodes. This can be done using standardized template that clients will be able to read. Clients can use these announcements to achieve a stable staking network through potential hosts, and form contracts with only those they trust considering the engagement history of the hosts
A contract requires consent from both the host and the client, allowing the provider to reject unfavourable terms or unwanted (e.g. illegal) files. The host may also refuse to sign a contract until the entire file has been uploaded to them. Contract terms give hosts some flexibility though they are vulnerable to denial of service attacks, which could prevent them from submitting engagement proofs or transferring files. It is the responsibility of the host to protect themselves from such attacks.
Client source code is hosted on the vidnix secure server to complete the block maturity, it is updated on the web and mobile application as each node will run separately, vidnix cloud servers are added into the active node chain then distributed through web/mobile applications. This allows a client to attain high staking network reliability.
The supply of Vidnix coins is fixed to 50 million, and all pos coins will be distributed as engagement reward and to stake holders as a block subsidy. The first block will have 50million coins mined. Following a target of 1 minutes between blocks, the annual pos percentage is 6% per year. The primary goal of vidnix is to provide a blockchain that enforces smart node contracts. The engagement rewards are directly linked to the proof of engagement submitted.
Vidnix is the worlds first smart node contracts based decentralised platform, offering multiple node hosts through a single chain. Where enterprise and peers can form a contract, these contracts can be used to enforce engagement agrements between clients and hosts, once a contract is formed the host must submit proof of engagement to the network (simply by creating, curating or by watching complete content posted on Vidnix network). The host will automatically be compensated for active engagement as per agreed contract conditions. Importantly, contracts do not require hosts to download entire blockchain on their devices, a simple Web/Mobile application is required to set a unique engagement id which then assigns nodes subjective to the requirement of the network, each user may serve to mature blocks for different client; in-bounds and out-bounds (running nodes and engagement rewards) would require an effective system one mechanism used would be the arbitrary data field in the blockchain.
Eathen V Davies Pronto Inc. Eathen@vidnix.io
Steffen Walderman Pronto Inc. Steffen@vidnix.io
Oksana Seredniak Pronto Inc. Oksana@vidnix.io