# Block proposal

## Inchoate micro-block

Round leader creates the key block and a sequence of inchoate micro-blocks filled with transactions.

flowchart RL
    A[Key Block]
    B(IMB 1) --> A
    C(IMB 2) --> B
    D(IMB 3) --> C
    Z(IMB N) -.->D

flowchart RL
    subgraph Block1
        direction RL
        kb1(Key Block 1)
        subgraph MB11
            direction BT
            imb11(IMB 1)
            mb11(MB 1) --> imb11
        end
        subgraph MB12
            direction BT
            imb12(IMB 2)
            mb12(MB 2) --> imb12
        end
        MB11 ==> kb1
        MB12 ==> MB11
    end
    subgraph Block2
        direction RL
        kb2(Key Block 2)
        subgraph MB21
            direction BT
            imb21(IMB 1)
            mb21(MB 1) --> imb21
        end
        subgraph MB22
            direction BT
            imb22(IMB 2)
            mb22(MB 2) --> imb22
        end
        MB21 ==> kb2
        MB22 ==> MB21
    end
    Block2 --> Block1
    Z[...] -.-> Block2

### Key Block structure

* Leader PK
* Ref Block ID (Prev Key Block or IMB)
* Meta Info *(version, timestamp, flags)*
* *KB_ID = HASH(LPK, Ref, Meta)*
* KB_Sig = SIG(KB_ID)

### Incoate micro-block structure

* Leader PK
* Ref Block ID (Key Block of previous Inchoate Micro-Block)
* Tx Root Hash
* Full Tx Root Hash
* *IMB_ID = HASH(LPK, Ref, TxRH, FTxRH)*
* IMB_Sig = SIG(IMB_ID)
* Transactions

### Micro-Block structure

* IMB
* LPK
* Ref
* TxRH
* FTxRH
* IMB_Sig
* Transactions
* Calculator PK
* Calculator Consensus
* Ref MB
* State Changes Root Hash
* Full State Changes Root Hash
* Proof of Calculation
* *MB_ID = HASH(CPK, CC, RefMB, IMB_ID, StRH, FStRH)*
* MB_Sig = SIG(MB_ID)
* State Changes

### Final Block structure

* Key Block
* Leader PK
* Ref Block ID
* Meta Info
* Signature
* Micro-Blocks
* MB 1
* IMB 1
* ...
* Transactions 1
* ...
* State Changes 1
* MB 2
* ...
* MB N
* *ID = MB_ID N*
* *B_SIG = MB_Sig N*

## Proof of calcutlation

State Changes are public information available to any member of the network. It can be easily copied by a dishones calculator claiming to be rewarded for the calculation performed. To prevent such behavior, the proof of calculation must not disclose the calculation itself.

The proposal is to use a STARK-like approach to conceal the proof data.

The calculator collects the identifiers of the functions used to calculate State Changes and writes them to the Merkle tree. To make the root hash unique, the calculator's public key is added to the Merkle tree as the first leaf.

flowchart TD
  R(Root Hash) --> A1( )
  R --> A2( )
  A1 --> B1( )
  A1 --> B2( )
  A2 --> B3( )
  A2 --> B4( )
  B1 --> D(Public Key)
  B1 --> E(Func ID 1)
  B4 --> F(...)
  B4 --> J(Func ID n)
  classDef selected fill:#f9f
  class R,A1,B1,A2,B3,B4,D,J,C selected;
  

On the next step it calculates root hash of the Merkle tree and uses if as a source of entropy to select Merkle branches.

The Merkle branch from calculator's Public Key, the randomly selected branches and root hash are provided as the proof of calculation.

Two levels of verification are possible.

At the first, basic level, everyone on the network can check that the provided Merkle branches produce the same root hash as in the proof.

At the second, full verification level, the verifier can repeat all calculations and recreate the tree completely using original calculator's public key. This way one can check that the root hash matches and that the random branches have been chosen correctly.

### Possible attacks

#### Random Function IDs

An unfair calculator can build a Merkle tree from a random set of function identifiers to simulate a calculation.