Skip to content

Latest commit

 

History

History
99 lines (68 loc) · 2.37 KB

MESSAGE.md

File metadata and controls

99 lines (68 loc) · 2.37 KB

Message format

The following document outlines a proposed format for Autobase OpLog messages

Clocks

A Checkout is a unique reference to another writers oplog. We reference their key, in compressed format, and the length of their core.

Checkout {
  key: c.fixed32,
  length: cuint
}

The clock used by the linearizer is an array of Checkouts

Clock: [Checkout]

Checkpoint

A checkpoint is a digest generated by the system. This is the system database treeHash and length. A checkpoint is stored each time the Autobase indexed length is updated.

Checkpoint {
  treeHash: c.fixed32,
  length: c.uint
}

Each oplog message stores a reference to the number of blocks since the previous checkpoint, and may optionally contain a Checkpoint (in which case checkpointer === 0).

checkpoint: optional(Checkpoint)
checkpointer: c.uint,

ABIVersion

The ABIVersion is a user parameter that describes the application indexing details. A node's ABIVersion will be avaialble in apply function, allowing application logic to handle index updates.

AutobaseVersion

The AutobaseVersion is a system parameter that describes the Autobase protocol being used. An upgrade to the AuotbaseVersion can be used to signal a new linearizing strategy / new OpLog message format / system db format.

Generally this should follow the npm module version.

OpLog Message

The overall message shall take the following form:

OplogMessage {
  AutobaseVersion: c.uint
  System: {
    checkpointer: c.uint,
    opt(checkpoint): Checkpoint
  },
  Node: {
    clock: Clock,
    abi: c.uint,
    batch: c.uint,
    value: bytes
  }
}

System

The System field contains system information. This should be unencrypted for mirrors.

Node

The Node field contains all data relevant to the linearizer. This can be encrypted to members only

Key Compression

v1.1 feature

A user acknowledges new writers using the Keys field which takes an array of keys. This optional field is available on every OpLog message and can be left empty.

Keys: [c.fixed32]

Instead of referencing full keys, we can reference the seq at which they are first acknowledged and the offset within the Keys array at which to find the key.

Key {
  seq: c.uint,
  offset: c.uint
}

Keys

This would add an optional Keys field to the message for wrtiers being added.