Akosh Farkash

@aakoshh

Joined on Jun 20, 2022

  • The purpose of this document is to figure out how to add the machinery needed for Hierarchical Consensus to Forest. NOTE: This was made on version 0.4 of the Forest codebase. It is currently 0.6 any some of the descriptions below no longer apply, for example Bitswap is used slightly differently. Code Exploration The following is a DFS walk of the major components, starting from the daemon entry point. daemon.rs: generate keys
     Like  Bookmark
  • This document is a collection of notes I took during preliminary investigation into the issues around gas accounting for memory usage. The main goal was to understand how to configure wasmtime, the Wasm library used by the FVM, so that we can achieve our goals for the FVM in an efficient manner. One concern was that we might end up over-allocating a lot of memory, or under-allocating and charging gas for copying memory around when the contract runs out of memory and needs to "double" it, which would be costly and slow. The other was how to enforce overall limits during contract execution. FVM Overview It helps to get an idea of how FVM works to understand what we want from Wasmtime. Each message (except transfers) included in a Block is handled by creating a fresh Wasm instance, loading the Wasm module corresponding to the Actor the message is targeted at, injecting all the functions supported by the host (e.g. interacting with storage), then invoking the execution, which can return some value. The interesting part from our perspective here is what happens when the Actor needs to talk to another Actor, if it needs to recurse.
     Like 1 Bookmark
  • This document contains notes and observations in preparation for using Narwhal and Bullshark as a custom consensus in Forest, similar to how Delegated Consensus was added. In particular we are looking at how to integrate the Mystenlabs Narwhal implementation, rather than starting from scratch. Narwhal + Bullshark Overview The basic premise of Narwhal is that it's DAG based atomic broadcast mechanism that can replace the mempool to radically increase throughput. Each node can have multiple workers ingesting transactions, batching them, then broadcasting them to other peers on the network. The atomicity comes from the fact that not only does it broadcast batches, it also collects a quorum of signatures from the receivers, and forms availability certificates to show that the transactions are available on a supermajority of nodes. Based on the local view of the DAG of transaction batch certificates, Tusk or Bullshark can establish a total order of transactions without further communication. Impact on Forest There are multiple ways to integrate this into Forest and Filecoin. So far we tried to preserve the basic notion of a Filecoin chain structure by constructing a chain that adheres to the longest chain rule, albeit with custom weights and validation rules.
     Like  Bookmark