Skip to content

Mining Miner Sync

hypercube-lab edited this page Sep 9, 2021 · 2 revisions

Miner Synchronization

Fast, dependable synchronization is the primary reason HyperCube can achieve such high throughput. Traditional blockchains synchronize on large blocks of transactions. By synchronizing on blocks, a transaction cannot be processed until a period of time known as "block time" has elapsed. In Proof of Work consensus, these block times must be very long (at least 10 minutes) in order to reduce the chances of multiple miners producing a new valid block at the same time. There is no such constraint in Proof of Stake consensus, but a miner cannot determine the order of incoming blocks without reliable timestamps. The most common workaround is to append a wallclock timestamp to each block. The timestamp is only accurate within an hour or two due to clock drift and network latencies varying. To get around the workaround, these systems extend block times to ensure that the median timestamp on each block is always increasing.

HyperCube takes a completely different approach, which it refers to as Proof of Dedication, or PoD. Leader nodes "timestamp" blocks with cryptographic proofs that a certain amount of time has passed since the previous proof. All of the data hashed into the proof must have happened before the proof was generated. The node then distributes the new block to miner nodes, which can verify the proofs. The blocks can arrive at miners in any order, and they can even be replayed years later. With such dependable synchronization guarantees, HyperCube can divide large blocks into smaller batches of transactions known as entries. Before any notion of block consensus, entries are streamed in realtime to miners.

Although HyperCube never sends a block, the term is used to describe the sequence of entries that miners vote on in order to achieve confirmation. In this way, the confirmation times of HyperCube can be compared to those of block-based systems. Block time is currently set to 800ms in the current implementation.

Under the hood, entries are streamed to miners as fast as a alphanode node can batch a set of valid transactions into an entry. miners work on those entries for a long time before voting on their validity. Because the transactions are processed optimistically, there is no delay between the time the last entry is received and the time the node can vote. If consensus is not reached, a node simply rolls back its state. This optimization processing technique, known as Optimistic Concurrency Control, was introduced in 1981. It can be used in blockchain architecture, where a cluster votes on a hash that represents the entire ledger up to a certain block height. It is easily implemented in HyperCube by using the last entry's PoD hash.

Connection to VDFs

HyperCube first described the Proof of Dedication technique for use in blockchain in November of 2017. In June of the following year, a similar technique known as a verifiable delay function, or VDF, was described at Stanford.

The fact that a VDF's verification time is very short is a desirable property. The approach taken by HyperCube to verifying its delay function is proportional to the time it took to create it. Split over a 4000 core GPU, it is fast enough for HyperCube's needs, but if you asked the authors of the paper cited above, they might (and have) told you that HyperCube's approach is algorithmically slow and shouldn't be called a VDF. We argue that the term VDF should refer to the entire category of verifiable delay functions, rather than just the subset with specific performance characteristics. Until that issue is resolved, HyperCube will most likely continue to refer to its application-specific VDF as PoD.

Another distinction between PoD and VDFs is that a VDF is only used to track duration. PoD's hash chain, on the other hand, includes hashes of any data observed by the application. That information is a two-edged sword. On the one hand, the data "proves history," implying that the data existed prior to the hashes that followed it. On the other hand, it implies that the application can manipulate the hash chain by changing the time at which the data is hashed. As a result, the PoD chain does not serve as a good source of randomness, whereas a VDF without that data could. The alphanode rotation algorithm in HyperCube, for example, is derived solely from the VDF height and not its hash at that height.

Connection to Consensus Mechanisms

Proof of Dedication is beyond a consensus mechanism, but it helps HyperCube's Proof of Stake consensus perform better. It's also used to boost the speed of data plane protocols.

Clone this wiki locally