Definitions

This page defines the core data structures and roles that exist in Hyperdrive.

Transaction

A transaction is a user-defined data structure that can be executed over some initial state, and execution plan, to transform it into a new output state. A transaction must be executed in full, or not at all. In this way, we say that transactions are atomic.

execute :: (Tx t, State s, Plan p) => t -> s -> p -> s

An ordered list of transactions can be also be executed over some initial state, and execution plan, to transform it into a new output state. The transactions are executed sequentially, and the output state of one execution is used as the initial state for the next execution. An ordered list of transactions can be executed in concurrently if, and only if, the final output state is equal to the output state that would result from sequential execution.

execute :: (Tx t, State s, Plan p) => [t] -> s -> p -> s
execute txs initState plan = foldr (\tx state -> execute tx state plan) initState txs

It is assumed that a transaction can be serialised to/from bytes as required by the peer-to-peer networking and persistent storage device. No other properties or functionalities are assumed.

class Tx t where
  serialise :: t -> [Byte]
  deserialise :: [Byte] -> t

Plan

A plan is a user-defined data structure that selects precomputed data for the execution of an ordered list of transactions over an initial state. The precomputed data that must be selected by a plan depends on the ordered list of transactions, the initial state, and the secure multi-party algorithm.

Given some ordered list of transactions and initial state, there exists multiple valid plans. Similarly, one plan can be valid for multiple ordered lists of transactions and initial states. However, the same precomputed data must never be selected by multiple plans, and a plan must never be used for execution more than once.

It is assumed that a plan can be serialised to/from bytes as required by the peer-to-peer networking and persistent storage device. No other properties or functionalities are assumed.

class Plan p where
  serialise :: p -> [Byte]
  deserialise :: [Byte] -> p

State

A state is a user-defined data structure that represents the application-specific state of the blockchain. Unlike other blockchains, Hyperdrive blocks do not store the application-specific state resulting from their own transactions. Instead, Hyperdrive blocks store the application-specific state resulting from the transactions in their parent block. This is because execution with a secure multi-party computation algorithm is interactive, and consensus on a block is not enough to know the application-specific state resulting from the transactions in that block.

The state known at height H+1 resulting from the state known at height H after all transactions at height H have been executed.

stateAtHeight :: Height -> State
stateAtHeight 0      = genesis
stateAtHeight height = execute (txs (blockAtHeight (height-1))) (stateAtHeight (height-1))

It is assumed that a state can be serialised to/from bytes as required by the peer-to-peer networking and persistent storage device. It is also assumed that the genesis state is known and is at height 0.

class State s where
  genesis :: s
  serialise :: s -> [Byte]
  deserialise :: [Byte] -> s

Block

Signatory

Message