VAPOR: A Value-Centric Blockchain that is Scale-out, Decentralized, and Flexible by Design

Abstract

Blockchains is a special type of distributed systems that operates in unsafe networks. In most blockchains, all nodes should reach consensus on all state transitions with Byzantine fault tolerant algorithms, which creates bottlenecks in performance. In this paper, we propose a new type of blockchains, namely Value-Centric Blockchains (VCBs), in which the states are specified as values (or more comprehensively, coins) with owners and the state transition records are then specified as proofs of the ownerships of individual values. We then formalize the “rational” assumptions that have been used in most blockchains. We further propose a VCB, VAPOR, that guarantees secure value transfers if all nodes are rational and keep the proofs of the values they owned, which is merely parts of the whole state transition record. As a result, we show that VAPOR enjoys significant benefits in throughput, decentralization, and flexibility without compromising security.

Appendices

A Algorithm $\mathtt{Proof}(v_j,B_i,\mathcal{CB})$

We define the proof of the ownership $P(v_j,B_i)$ as a subset of $\mathcal{CB}$ that output by an algorithm $\mathtt{Proof}(v_j,B_i,\mathcal{CB})$ shown in Algorithm 2.

B Proof for Theorem 1

Proof

Firstly, we prove Ownership by induction. It is clear that the first owner of any value $v_j$ will have the proof of this value, which are basically all of his public key and his own confirmed transaction blocks until the block before the one that spends it. Then, assume that the t-th owner of $v_j$, denoted by $o_t$, has the proof $P(v_j,B_k)$ proving the ownership $O(v_j, B_k)=o_t$ at state $B_k$. Then, assume that the $t+1$-th owner, $o_{t+1}$ starts to own the value at state $B_i$, i.e., $O(v_j,B_{i-1})=o_{t},O(v_j,B_i)=o_{t+1}$. Then, by the definition of proof, there exists a transaction in $b_i(o_t)$ that send the value to $o_{t+1}$. By the Rationality of Holding Value in RVO, $o_t$ would not make this transaction unless he would like to send this value. Then, by the Rationality of Sending Value in RVO, $o_t$ will take responsibility of giving proof $P(v_j,B_i)$ to $o_{t+1}$. Again, by the definition of proof, $P(v_j,B_i)$ is merely $P(v_j,B_k)\cup \{b_l(o_t): k<l \le i\}\cup \{\text{ public } \text{ key } \text{ of } o_t \}$, which can be independently provided by $o_t$. Hence, we prove that in this case $o_{t+1}$ will eventually has the proof $P(v_j,B_i)$. Furthermore, it is clear that only the owner of a value could transfer it as a transaction must be included in a block confirmed with the private key of the owner.

Then, we prove Liquidity. To transact a value, the owner simply needs to put a transaction in a confirmed transaction block. Then the property (Partial) Synchronous Liveness in Property 1 guarantees that the transaction block can be confirmed as the abstract will be included in the main chain.

At last, we prove Authenticity. This is actually guaranteed by the design of VAPOR. Firstly, the initial ownership of a value is unambiguous because it is on the main chain which has Asynchronous Consistency in Property 1. Then, the ownership transition is always determined by a confirmed block which is immutable. Then, there are three possibilities for the number of transactions of the same value in a confirmed block: (1) if there is no transactions of that value, then the ownership remains unchanged; (2) if there is one transaction of that value, then the ownership is changed to the receiver; (3) if there are more than one transactions of that value, then the ownership becomes NA. Since all three possibilities result in unambiguous ownership, we proved Authenticity. $\blacksquare$

C Verification Algorithm for Value Division $\mathtt{GetOwnerDV}$

Here we introduce $\mathtt{GetOwnerDV}$ in Algorithm 3. Note that in here, a minor modification should be made on GetOwner so that the result will not be ‘Fail’ if redundant elements are detected in p.

D Off-chain Payment Scheme

Our fast payment scheme contains two new type of transactions, two new types of message to the main chain, and a new verification algorithm $\mathtt{GetOwnerFP}$. If node x wants to make fast payment to node y, he simply performs the following:

• Node x makes deposit transactions to lock up a number of values with indications that they could only be send to y, confirm the blocks, and send them to node y to initialize the fast payment.

• When a fast payment of value $v_j$ is issued, node x sends a signed transaction of $v_j$ to node y, denoted by tx. Then, node y can include this transaction in his own blocks at any time and confirm them to receive the value.

• When node x wants to end the fast payment and unlock a value $v_k$, he sends an unlock message to the main chain.

• The unlock will succeed in T rounds if no objection message shows in the main chain. An objection message can be made by any node by sending tx to the main chain.

Then, in $\mathtt{GetOwnerFP}$ we define three new rules on checking the proofs for ownership:

• 1. A value $v_j$ locked by node x is no longer considered as owned by x, but NA indicating no owner. It will be reconsidered as owned by x if there is only one unlock message is on the main chain, assume that it is included in $B_i$, and there is no objection message included in $B_k, i+1 \le k \le i+T$.

• 2. A value $v_j$ is transacted from node x to node y in state $B_i$ if it is locked by node x to send to node y at a state $B_{i'}, i'<i$, and there is a signed transaction by x included in block $b_{i}(y)$. There should not be a unlocking message for this value on the main chain that is not responded for more than T blocks.

Note that although a fast transaction is only confirmed when the block is confirmed, the transaction itself is completed as soon as the signed transaction is received by node y, since node y can then independently make the proof of him owning this value.

Some drawbacks in existing off-chain payment schemes, e.g., LN, are: (1), the values in the transactions and deposit will be locked until the channel is closed. Hence, it is a different type of transaction and can only be considered as a supplement to the value transfer system. (2), the receiver should have a certain synchrony, i.e., the receiver should be able to issue a transaction to the chain to take the deposit before it is refunded to the sender when he catches the sender cheating. (3), the security of this scheme is not formally proved. A big advantage of the off-chain payment scheme in VAPOR is that node y can spend $v_j$ as soon as he owns it, without requiring shutting down the whole channel, i.e., all deposit values been spend or unlocked. Moreover, we could use similar arguments as the proof in Subsect. 4.3 to prove the Ownership property holds when the network is synchronous and the RVO rules apply.

E Betting Game

Here, we give a smart contract for on-chain betting. Node x and node y would like to bet even or odd on the hash of block $B_i$. Then, we simply add a new type of transaction which is $Bet: [v_j,x,y,B_i,sn]$. The bet transaction will lock the value $v_j$ until $B_i$ with one unlocking condition: another value with the same amount is bet by y before $B_i$ with x and the ownership will depend on the hash of $B_i$. Then, the verification algorithm is simply checking the lock transaction, the ownership for both values, and the hash of $B_i$, i.e., if node x bet on even, then the ownership of both locked values will be node x at state $B_i$ if the hash of $B_i$ is even.

However, the difficulty is to make sure that both node x and node y could get the proofs of ownership and the locking message for both values. This is a problem since there is always one node in the betting would benefit from not sharing the proof and/or the locking message, which will cause a scenario similar to Two Generals Problem. As a result, the verification algorithm must also check for a confirmation send by one node on the main chain, which shows the agreement for both nodes that both proofs are acquired. Without such confirmation, the value will be unlocked at state $B_i$ to its original owner.