The innovating part of Viva is not so much its blockchain, but its lack of a blockchain.
Blockchains are wasteful and expensive places to store data. As Bitcoin has been learning with lightning network, blockchains are most useful as stores of timestamped references to data, rather than the actual data.
This is why the first piece of the puzzle for Viva is to create the Viva UnLimited Content Addressed Network, aka VULCAN.
This design document is intended for implementors and thus it may be a bit spartan on the flowery details. We have fundamental assumption that the reader is well versed in JSON, WebRTC, Golang, and Javascript. If this isn't you, then you are not the intended audience.
VULCAN is a P2P content addressed network using WebRTC. VULCAN was custom created for the Viva ecosystem and as such takes a very different appearance to almost everything.
VULCAN has a merklerchain similar to a blockchain, but there is no block height per se. Only a timestamp. Each block is addressed by timestamps or blockhash. A new block must reference an older block. The blocks track requests for data retrieval that have filled. The chain maxes out at 18 months length.
Blocktimes are 60 seconds. Blocks are considered valid if thy are entirely new content. Each block builds off delta previous blocks. This allows for forks to resolve naturally, since multiple forks can be merged into a super block as long as all of them feature exclusively new content.
In the event that one or more blocks in a fork are not exclusively new, the block and
all of its children are pruned, the transactions imported into a new super block.
Super blocks are once daily snapshots of all balances. Also called a "page" in previous papers I've published. It references a previous page, details all transactions since then and provides a daily summary of all balances.
You can refer to the Viva white paper for more details.
VULCAN messages are all JSON. The payload, whether text or binary is Base64 encoded.
A VULCAN message must contain the following fields...
Type: "request"/"response"
ID: unique message id. Note that each response must use the request msg id
Request messages should have a priority and a bid field.
priority:[0...5] 0 is life or death emergency, 5 means this is not high
bid: Quantity of viva, bid by the requestor.
The operation field determines much of what happens next. Valid operations are based on HTTP verbiage and the API is restful.
PUT, GET, POST, DELETE
PUT inserts data into the blockchain.
GET retrieves data from the blockchain.
POST updates data on the blockchain, producing a new version.
DELETE marks data as unused and safe to prune.
The post operation will set a new HEAD version against the base object, with the changed attributes. Please note that at this time there is no provision for packed deltas such as those present in git. Deltas are applied, but objects are copied. This is due to the fact that every object has a max age and may eventually be pruned automatically.
The next fields are the payload/manifest. Any object smaller than 4M:B should be included in a payload. Any object greater in size should be sliced into 4M:B chunks, each chunk given its own VULCAN object and the id referenced in the manifest, in lieu of a payload. If manifest, then you also need m of n fields in the chunk.
All VULCAN messages are JSON objects transmitted over WebRTC data channels.
It is beyond the scope of this document to discuss individual libraries and their particular semantics.
For the purpose of our pseudocode, we will assume a library with a controller entailed WebRTC. This library will be assumed to auto handle connection state and our entry point will be OnMsgRecv
The library will have a method "Send to Group," which will handle sending messages further on.
There is a 5 of 8 group assumption. Meaning each peer connects to 8 other nodes, at least 5 of which cannot share a common peer.
By enforcing this restriction, we ensure the network spreads out efficiently and does not centralize around a handful of hyperconnected nodes.
Thus upon initial connection to a node, a peer list is requested and checked against existing connections.
Ideally when connecting to a new node, the only common per list entry should be the one that referred to the peers.
Obviously though, this is an ideal and the reality is that there will be need to initially form heterogeneous bootstrap groups and then evolve towards 5 of 8 later.
Once connections have been established, it is important that some amount of flow control be applied to the network to prevent flooding.
We use a concept of slots. Each slot is 100 ms. But instead of turn taking, each node picks a random number. The last 4 digits correspond to a slot. Next, you broadcast the number and slot and begin hashing the number repeatedly, hash mod slot=0 and its your turn.
This provides a predictable yet stochastic flow control mechanism. In periods of extreme lead, we can also easily ad a proof of work hash to the message and only forward messages with a sufficiently high proof of work.
I will post more soon, STAY STRONG and thank you for your support!
Darth Vader photo courtesy of
Nimoy