Overview of SmallTime
Overview of SmallTime
For context, please see this post.
The SmallTime network consists of a single class of nodes. Each node has made best-efforts connections to as many other nodes as it can, to form a distributed network. Each node runs the same version of the SmallTime protocol. Each node has the same starting version of the blockchain. These are the initial conditions.
The operator of Node A wants to make a transfer to the operator of Node Y. For this to occur, the transfer must be reflected on a universally accepted version of the blockchain. A Proof of Work is required to update the blockchain. Neither Node A nor Y may complete the Proof of Work for their own transfer. These are the ending conditions.
Preparing the transfer request
Node A prepares a message consisting of version, input address, amount, output address, time, signature, etc. This is similar to the Bitcoin specification.
Node A hashes the message (using SHA-256 or an equivalent) until the hash begins with a certain number of zeroes. The hash is appended to the message to form a transfer request. The hash is a Proof of Work intended to deter spamming the network. The difficulty level of the Proof of Work can be set so that a single transfer is not impeded. However, sending many thousands / millions of transfers (as with spamming) will incur a cumulative computational cost. This PoW does not effect the blockchain. This methodology is inspired by HashCash.
Node A floods the transfer request to the SmallTime network. However, the network will not propagate the request because Node A has not yet attempted to publish a block to the blockchain.
The Proof of Work
Node A hashes its transfer request to create HashA. In doing so, Node A has “mapped” its transfer request to a pseudo-random location in the circular identifier space Hash Space. This is inspired by KARMA.
Node A gets outstanding transfer requests from the network. This is the beginning of the Proof of Work required to publish a block. Node A is building a list of transfer requests which it will use in its Proof of Work. Node A has an incentive to get as many transfer requests as possible from the network. This is also an incentive to be as well-connected as possible.
Node A is looking for transfer requests which, when hashed, will be within Range R of HashA in the Hash Space.
Node A:
- Takes each transfer request
- Verifies the inputs/outputs
- Hashes the transfer request
- Checks if the transfer request is within Range R of HashA in the Hash Space
- If the hash is within Range R, it is a Neighbor Hash
Node A has completed the Proof of Work once it has found [X] Neighbor Hashes. This means that Node A repeatedly hashes different transfer requests, looking for hashes that fall into a certain range. This is equivalent to Bitcoin’s Proof of Work, where Node A repeatedly hashes different numbers (by incrementing the nonce) to find a number that begins with at least a certain number of zeros (falls into a range). The difficulty of the SmallTime Proof of Work can be adjusted by: inc/decreasing Range R, or inc/decreasing [X]. Thus, the computational difficulty and speed of block creation can be regulated.
Updating the blockchain
Once Node A has found [X] Neighbor Hashes, it assembles the transfer requests behind those hashes into Block A. Block A consists of the header of the previous block and has similar specifications to a Bitcoin block. Thus, Block A builds on the existing blockchain.
Node A broadcasts the block to the SmallTime network.
Other nodes see Block A. They verify that the hashes inside of Block A are within Range R of Hash A in the Hash Space. This lets them check to see that Node A has done the Proof of Work for a certain number of other transfers. If true, each node will propagate Block A. Each node will also propagate A’s own transfer request. The node has “validated” the Hash Space around A as having done the Proof of Work.
Block A spreads across the network. Once it is universally accepted, the transfer requests within Block A have been completed.
A’s transfer request also spreads across the network. As it spreads, the chances of it being included in the next block increase. Eventually, Node A’s request is included in a block that is universally accepted. Node Y sees that the transfer has been completed.
Node A has completed a Proof of Work to allow other transfers to succeed, and Transfer AY has been successful. The ending conditions are met.
Some notes
I believe that SmallTime will result in a safer, quicker, and larger transfer network than Bitcoin, where the network and its transfer resources scale at at least 1:1. However, I am not a cryptographer, distributed systems analyst, or mathematician. Below, I discuss advantages / disadvantages which bear modeling / further analysis.
SmallTime is more secure against attack
In Bitcoin, mining nodes choose which transfers they include in their attempt to update the blockchain. This creates the risk of censorship. A miner (or pool of miners) can choose to only include certain transfers, or always exclude other transfers, from their blocks. The same method allows double-spending and other attacks. These attacks require miners to have consistently better odds of winning the Proof of Work AND universally propagating their updates to the blockchain. In order to do so, they must control 51%+ of the network (or less). This has already happened.
In SmallTime, the nodes cannot select which transfers they include in their attempt to update the blockchain. The transfers are randomly assigned based on their own transfer request’s position in the Hash Space. I believe that this randomness makes it very difficult for a group to censor/promote certain transfers, as they cannot select which transfers they include in their blocks. The only way to censor/promote transfers would be to control more than 51% of the active transfers on the network. Each transfer request message must include a (albeit individually simple) Proof of Work. The cumulative cost of these Proofs necessary to control 51% of active transfers on such a large scale network seems unbearable for any group. This bears further modeling.
SmallTime supports an easier Proof of Work
Bitcoin is primarily secured by its CPU-intensity. Bitcoin’s Proof of Work is currently so difficult that it requires processor farms and specialized chipsets to complete in any reasonable amount of time, let alone win. A successful attack on Bitcoin has two requirements. Attackers must (1) censor/promote certain transfers by (2) owning 51% of the network’s processing power. The CPU-intensity of Bitcoin’s Proof of Work only concerns itself with the latter portion of this statement. It makes it expensive to control 51% of the network’s processing power. The Proof of Work does not make it difficult to censor/promote transfers.
SmallTime, however, directly achieves both requirements. It (1) prevents attackers from censoring/promoting certain transfers by randomizing which transfers must be included in a block. It (2) makes controlling 51% of transfer requests cumulatively expensive by requiring that a simple Proof of Work be included in each transfer request. Finally, it requires that each node complete another Proof of Work before its own transfer request is propagated throughout the network. Randomizing transfers is not CPU-intensive. I believe that introducing a non-CPU intensive security feature allows SmallTime to reduce the difficulty of its central Proof of Work. Furthermore, preventing the ownership of 51% of transfer requests as opposed to 51% of CPU power places the CPU burden on attackers, not honest nodes. I believe that these factors allows SmallTime’s central Proof of Work to be less difficult than Bitcoin’s. This should allow for mobile phone / casual CPUs to participate in SmallTime. This also bears further modeling.
SmallTime disincentivizes Selfish Mining
Bitcoin may be vulnerable to Selfish Mining, a strategy which rewards withholding “winning blocks.” In effect, by not communicating regularly with the network, Selfish Miners are more likely to win future blocks than honest miners. This leads to more miners joining Selfish Mining pools until the Selfish Miners control over 51% of the network. Selfish Mining works because Bitcoin does not directly reward communication/connectivity in its Proof of Work. Being well-connected to the rest of the network does not impact the speed of the Proof of Work.
SmallTime rewards connectivity directly in its Proof of Work. The better connected a node, the more likely it will find Neighbor Hashes in the transfers it gets from the network for its Proof of Work. Connectivity is also rewarded as better connected nodes will have their blocks spread more quickly, which allows their transfer request to spread more quickly as well. This increases the chances of their transfer request being addressed by other nodes. I believe that the benefits of better connectivity reduce the risk of Selfish Mining-type attacks. This also bears further modeling.
Potential instabilities
Forking. Bitcoin blocks take ~10 minutes for the network to solve, and ~60 minutes to be “mature” (unlikely to change ever again). Requiring ~10 minute intervals per block allows orderly updates to the blockchain, with few forks (when there are two or more competing blocks). SmallTime will have more blocks simultaneously published as less difficult work is required per block. This will lead to more forks. Requiring multiple Neighbor Hashes per block will ensure that all transfer requests are eventually addressed. Whether this system is stable requires further modeling.
Freebies. SmallTime makes it unlikely that a user’s transfer request will be addressed without their first completing the Proof of Work for another transfer. However, it is not impossible. Whether this system is stable requires further modeling.
Illustrations courtesy of the wonderful @bettinauxd
Please tweet any comments to @dbrgndl
/end.
