github: https://github.com/protocol/ConsensusLab/issues/13 :::info % COPY THE CONTENT OF THIS BLOCK! 2022-01-01 ✋ Attendees Christian Luca Duc @sa8 @vukolic

Moved ------> here

June 2022 The goal of this document is to give a quick walk-through of the implementation of HC with pointers to the right places in the code (of the MVP). Notes on current implementation Disclaimer: While we were attempting to create code as close to production as possible, the code is in an MVP stage. We had to de-risk several parts of the design to evaluate if "it was actually possible". Adding to this the lack of detailed reviews/audits of the code, we may have left horrible things behind so please feel free to suggest any changes, improvements and report potential bugs or flaws. Decoupling consensus interface: https://github.com/filecoin-project/eudico/blob/eudico/chain/consensus/iface.go

Introducing Hierarchical Consensus Simple Summary To increase the range of use cases that the Filecion network can support, and to overcome future scalability limitations in terms of throughput and finality of the Filecoin blockchain, this FIP introduces Hierarchical Consensus (HC), a framework to scale Filecoin horizontally. HC enables Filecoin users to spawn new subnets from the Filecoin network. Subnets instantiate new independent state and are able to run their own consensus algorithm. Subnets interact seamlessly with the Filecoin mainnet while parallelizing the validation (and execution) of messages. Our framework enables application developers to host their applications in networks with the appropriate security-performance trade-off. This FIP introduces: The architecture of Hierarchical Consensus, and how it integrates with the Filecoin network. A new Consensus interface that decouples the specific consensus implementation used for the different networks, and allows the Filecoin stack to interact and use any consensus implementation that follows the interface. This interface is shared by all HC-compatible subnets and consensus algorithms.

Motivation Blockchains based on a reusable resource (such as proof-of-stake or proof-of-space) are not as secure as those based on proof-of-work. Specifically, they are vulnerable to long-range attacks (LRA), where an adversary can create a long fork very cheaply. Long-range attacks rely on the inability of a user who disconnects from the system at time $t_1$ and reconnects at a later time to tell that validators that were legitimate at time $t_1$ and left the system (by e.g. transferring their stake) are not to be trusted anymore. In a PoS system, where the creation of blocks is costless and timeless, these validators could create a fork that starts from the past, i.e. at time $t_1$, and runs until the present. This is unlike, for example, proof-of-work (PoW) systems, where creating blocks requires time and money (e.g., performing actual computation) and not just using cryptographic keys. A user would be unable to recognize the attack as they are presented with a "valid" chain fork. Because the past keys of a given chain fork do not hold value in the present on that fork, previous validators can easily be bribed by an adversary intending to perform this attack. With project Pikachu, we propose to design a checkpointing mechanism that leverages the security of proof-of-work blockchains by anchoring the state of the Filecoin chain onto the Bitcoin blockchain. In the case of long-range attacks, the Bitcoin chain can be used to determine the honest chain. We present our current design below, before explaining its limitations and some associated open problems. In short, we came up with a design that leverages Schnorr threshold signatures supported by the 2021 Bitcoin Taproot upgrade. However, we still need to scale the solution to accommodate PoS and related weighted consensus protocols (such as Filecoin's Expected Consensus), which feature possibly thousands of miners/validators. Existing design

This is a temporal document discussing how Eudico clients can start (spawn) a Mir chain. Persistent Nodes Even if Mir's validator set is static, Mir validators must know the network addresses of each other to start communications. This approach suggests that each Eudico client is provisioned with Mir persistent nodes string in the following formatID1@Addr1, ..., IDN@AddrN. This string is passed via environment variable EUDICO_MIR_CLIENTS, client ID of each node is defined as SubnetAddress:Address, for example /root:t1ozbo7zqwfx6d4tqb353qoq7sfp4qhycefx6ftgy. Hierarchical Subnet This approach uses the hierarchical consensus framework.

List of ideas for learning resources. Feel free to contribute with additional resources you may have found useful, and that others may also like. Books The Rust Programming Language (Alfonso) Rust for Rustaceans (Denis) Crafting Interpreters (Alfonso) TCP/IP Illustrated (Denis) Database Internals (Denis) The Pragmatic Programmer (Sergey)