Blocktree

Project Road Map

In broad strokes, theses are the phases of development.

Phase 1: Foundations

• Definition of the main data types.
• Definition of the binary format used to serialize all data structures. (Done 2022/04/14)
• Creation of a cryptographic abstraction layer which will defer to openssl for the time being. This module will include type definitions for hashes, keys and signatures. It will define functions for:
  1. Symmetric encryption and decryption.
  2. Asymmetric encryption and decryption.
  3. Asymmetric signing and verification.
  4. Higher level functions for operating on blocks, read caps and write caps.
• Implementation of a block manager for persisting blocks to disk and retrieving them when needed. We need to make sure the page cache is being used while doing IO here.
• Implementation of a cache for block keys.
• Definition of an RPC interface for sending commands to and receiving responses from a node via stdin.
• Creation of a crate called harness for running nodes as child processes and communicating with them. This crate must define high level functions for:
  1. Preparing a directory for a new node.
  2. Starting a node.
  3. Sending commands to a node.
• Creation of a crate called test-harness which uses harness to write tests for nodes. This crate should be capable of starting multiple nodes to test their interaction.

Phase 2: Networking

• Definition of the data structures sent as messages over the network.
• Implementation of a listener in the node which processes these messages.
• Notifying other nodes when a block has been written.
• Implementing distributed locking via leader election.

Phase 3: Programming Interface

• Define a package format for user code. This should consist of a WebAssembly binary along with a manifest containing metadata about it, such as which principal authored it and which permissions the app is requesting. This manifest must be cryptographically signed.
• Define an API for user code and which exposes the following capabilities:
  1. Read and write blocks (with permissions checks).
  2. Send messages to other nodes (which may or may not be in the same tree).
  3. Lock a file for exclusive access.
  4. Register a callback for when a file is modified by someone else.
  5. Make HTTP requests.
  6. Register callbacks to handle HTTP requests.
  7. Open arbitrary network sockets. (Should this API extend WASI?)
• Implement a crate which can run WebAssembly code in a sandbox.
• Define an IPC interface between the sandbox and the node.

Phase 4: Blockchain

• Define the data structures needed to construct a blockchain.
• Implementation the mining algorithm in the node networking module.
• Implementation of the logic needed to determine the level of redundancy desired for a given block.
• Implementation an abstraction layer for Erasure Encoding. Define high level functions for creating Fragments from a Block.
• Implementation of the advertising, negotiation and agreement process by which nodes store fragments with other nodes.
• Implementation a Fragment manager in node which handles persisting fragments to the filesystem and retrieving them when needed.
• Registering an endpoint (IP address and port) for a principal.
• Creation of an index which is created from the block tree and which allows efficient look up of node IP addresses and the holders of the fragments created by a given path. This index is updated every time a new block is added.
• When a new block is added, the transaction fees from it are collected and new currency is created for each new fragment which is stored. These funds are then transferred to the principal who mined the new block.

Phase 5: Integration

• A webapp which provides a user interface for nodes. This should be able to:
  1. Create a new root key.
  2. Backup and restore a password protected root key to external storage.
  3. View and approve write cap requests.
• Creation of a linux distribution to run the node and webapp.
• A FUSE filesystem daemon for mounting a block tree in a filesystem.
• An Android app which runs a node.

Phase 6: Essential Applications

• App for visualizing and managing a block tree.
• A contacts app.
• An object oriented database.
• A micro-blogging app.
• A picture/video app.
• A voice/video chat app.

Phase 7: Hardware

• Design and manufacture a router with a hard drive that runs the linux distribution created previously.
• Create a custom Android distribution which runs a node on start up.
• Design and manufacture a phone which runs this Android distribution.

Phase 8: The Multiverse

• Create an app which functions as a server for a metaverse. This app will manage objects in a metaverse.
• Create a client that run under Windows. The client will be responsible for rendering the object data it receives from the app and updating objects based on user input. This client must have VR and mouse and keyboard support.

Outline of paper

*Overview Cover major features of the system and describe how it uses and improves traditional web technologies.

*Data Definition Define the format of: -Keys -Blocks -Directories -Files -Paths -Messages -Fragments -Programs

*Node Definition Describe the roles and responsibilities of nodes: -They provide an API to programs -Persitence of data locally and over the network. -Forwarding BlockTree messages and HTTP requests to authorized Programs. -Handling BlockTree messages from the network that are for the node

itself.

-Secure management of cryptographic keys using a TPM. -Forwarding traffic to other nodes. -Resolving node IDs to IP addresses.

*Network Definition -Mechanism to resolve node IDs to IP addresses. -Node hierarchy and leader election among peers. -Distributed Block locking for exclusive writes. -Opportunistic concurrency by default, with the rule that the last write known to the leader is the winner. -In order to participate in the network a node must have a valid TPM. The issuance of these TPMs is controlled to prevent inflation. When a TPM is first connected to the network it is claimed by the party who first registers it. The currency associated with that TPM is then transfered to the party. -Nodes store fragments for other nodes when they are paid. Two nodes create a contract store it in the public blocktree when they agree to do this. -Nodes can also create contracts to forward traffic for each other.

*Program API -Provide file creation API. Blocks can be created which are good for reading sequencially or good for reading randomly. -Provide binary file IO. The caller provides a plan-text Path and can open a block for reading, writing, or both. The API should stream based. -Provide stream wrappers for doing text IO. -Provide API for registering callbacks to be notified when blocks are modified. -Method to lock a block for exclusive write access. -API to register callbacks to handle BlockTree and HTTP requests. -A method to send Messages to other nodes and HTTP requests to other hosts.

*Applications -A distributed document database:

 Find or create a library for reading and writing BSON files and use
 it for storing data.

-A web development framework which allows one to register middleware to handle HTTP requests. Provides Request and Response abstractions to middleware. -If time allows create an MVC middleware implementation. -A middleware implementation for serving static content. -A video streaming server. -An application for managing contacts. -A secure messaging and chat application.

Performance Measurement with flamegraph on Linux

In order to use the flamegraph crate to on Linux you need to setup unprivileged access to the perf utility by your user account. After installing perf (on Arch with pacman -S perf), perform the following as root (if perf is not installed at /usr/bin/perf use which perf to locate it):

# groupadd perf_users
# cd /usr/bin
# ls -alhF perf
-rwxr-xr-x  2 root root  11M Oct 19 15:12 perf
# chgrp perf_users perf
# ls -alhF
-rwxr-xr-x  2 root perf_users  11M Oct 19 15:12 perf
# chmod o-rwx perf
# ls -alhF
-rwxr-x---  2 root perf_users  11M Oct 19 15:12 perf
# setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf
# setcap -v "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf
perf: OK
# getcap perf
perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep

(source: https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html) Finally add your user account to the perf_users group:

# usermod -aG perf_users <your username>

You'll need to logout and back in for the new group to take effect. You can confirm you're in the group with:

> groups
tss audio <your username> perf_users

The you can run flamegraph as your user account with:

> cargo flamegraph --unit-test <crate name> -- test::<test name>

(source: https://crates.io/crates/flamegraph)