Skip to content

Documentation (WIP)

Martijn de Vos edited this page Oct 6, 2020 · 1 revision

Consistency and validity of data are fundamental properties of distributed systems. Consistency implies that all peers in the network have the same log entries persisted to their local knowledge base. BAMI guarantees strong eventual consistency (SEC) through the continuous exchange of log entries. This property does not imply that peers agree on the state. This state is computed by a state machine that applies all locally known transactions in order. The state machine assesses the validity of each transactions against the current state given some application-specific integrity guarantees. The state machine is usually bundled in the software. Therefore, one can, in practice, assume that most peers operate the same state machine.

Existing blockchains, e.g., Ethereum and Bitcoin, mix consistency and validation, both in the protocol design and implementation. For example, the executing of the Bitcoin scripting language is embedded in the consensus protocol used by Bitcoin. BAMI, however, has a clear separation between consistency and validity which is reflected in the implementation. This separation allows flexibility, e.g., applications with lower security requirements can choose to leverage SEC while avoiding transaction validity.

Data Structure

The information in BAMI is organised in two types of chains:

  • Personal chain: the information created by one peer is kept in the chain, linked with each other. This imposes a sequential order of information by a single writer (see PRAM). This is a convenient way to verify and synchronise related data.
  • DAG representation of a chain: if a fork is detected in sequential chain we stop interacting with the malicious peer and provide opportunity to fix this inconsistency. Chain as a DAG follows Causal Consistency.

Blocks

Blocks are the smallest data unit in the BAMI mechanism. In contrast to existing blockchains, each block in BAMI contains one transaction payload, created by a single user. Each block is digitally signed by its creator. Each block also contains a type field, a string value that identifies the application in which the transaction lives.

A block contains two sequence numbers. The first sequence number represents the index of the block in the personal chain. The second sequence number indicates the index of the block in the community chain. Note that it is possible that two users create two blocks with the same community sequence number (i.e., a simultaneous write to the community chain).

Each new block created by a user links to all known blocks within the same community that do not have an incoming pointer. We call such blocks terminal blocks.

Communities and Sub-communities

BAMI organises peers with similar interests within the same community. Each community maintains a part of the global BAMI graph, specifically, the subgraph containing blocks with a specific community identifier.

Any developer can easily create their own communities with custom functionality and policies. By default, BAMI starts a main community, which can be considered as the coordinator for different sub-communities.

TODO explain factories

Network Primitives

BAMI builds upon the IPv8 networking library. This existing library has rich support for the creation of decentralised overlay networks. Furthermore, it offers authenticated messaging and decentralised NAT puncturing. Messaging between peers in BAMI proceeds using the unreliable UDP protocol. IPv8 is also responsible for peer discovery within communities.

Frontiers

At the core of BAMI lies a primitive, yet effective gossip mechanism that ensures strong eventual consistency of data elements. When a peer joins a BAMI community, it will continuously disseminate the frontier to a subset of discovered peers within each community, by default, every half a second, and speeds up the convergence of information across peers within the same community. The frontier is a short description of the community DAG. It consists of the following three-tuple:

  • Terminal blocks: The terminals are a list of blocks within the same community that do not have a successor (incoming hash pointer). When creating a frontier for a specific community, a peer includes all terminal blocks.
  • Holes: This is a list of ranges that indicate the community blocks that a specific peer is missing.
  • Inconsistencies:

BAMI guarantees that all peers will eventually have the same frontier, given that there are no writes to the community DAG.

Frontier Reconciliation

TODO

Clone this wiki locally