OverChain: “A Robust Overlay”
OverChain presents a robust overlay designed by Jason Conley. This overlay enhances the functionality and resilience of the system, offering improved performance and durability. Explore the innovative solutions implemented by Conley to create a more efficient and effective network overlay. Dive into the intricacies of OverChain's technology as it integrates this robust overlay to elevate its capabilities and provide users with a seamless experience.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
OverChain: A Robust Overlay Jason Conley
Background DHT hypercube made up of committees at each vertex Theoretical, no implementation in the strict sense Bitcoin is susceptible to network partition attacks, because of the weak assumptions / connections of the overlay
The Eclipse Attack and how to prevent it Eclipse attack Essentially partitioning a peer to the point where their only source of information is from adversarial peers From this point, selfish mining, double spending, etc. Do Replication for connections, make committees Adversaries now must maintain multiple peers to overwhelm connections Something like a Cuckoo rule to prevent byzantine committees Distributed random coin flips, local randomization from global string
Issues with current solutions The methods mentioned before are expensive in either computation or message passing They also assume that a joining peer will have contact with an honest node each time or that these peers are random, i.e., the bootstrapping problem Essentially, we need something that can handle (more or less): Coordinating a dynamically sized network (bootstrapping problem) Byzantine nodes
The Blockchain! Rather the OverChain The authors want to store information on chain to coordinate a dynamic network and handle byzantine interference The information will be an ID for 1 node The chain of blocks storing ID s will be the directory The directory is X blocks long. X = an order of block time * log^2 (N) It will manage new peers joining the network The ID is chosen by the miner of a block, and the ID is from the miner s committee. The promoted node manages a set of committees
The Directory A directory will manage some order of B * log^2(N) blocks. A bucket is some order of log^2(N) blocks long This guarantees at least log(N) honest peers in a directory Buckets move through phases . Each pertaining to the blocks position in the directory A directory has a predetermined mapping from committees to buckets. Any two buckets in a directory reside over disjoint sets
The Join Algorithm Node Q wants to join the network via node P, Q must provide a proof to join. P must proof-of-work Q s join proof to allow the peer in P requests the contact info about a committee c from all nodes in the directory that relate to c If the join request was recent enough Q is allowed to send its info to the committee and it has officially joined Due to logarithmic redundancy, it takes O( log^3 (N) ) messages for Q to join the network
Handling Large Shifts in Network Size All nodes know the number of nodes in their committee A random committee broadcasts the size of their group All nodes use this knowledge to guess the new network size, and then reconstruct the hypercube as needed
Recovering from Catastrophic Failures Two requirements to recover from failure: 1. The joining process is not affected 2. A large fraction of honest peers can run the blockchain protocol The blockchain itself guarantees this With these two guarantees, the blockchain will persist and new nodes will become directory nodes, new committees will form as lifetimes run out A note about node lifetimes: Directory nodes are alive for the duration they are part of the directory. Non-directory nodes have a lifetime of half-life / X log^2 (N)
Recap The authors handle coordination / churn by putting ID s on the chain and having them coordinate together the join process Handle byzantine nodes with node lifetimes, properties of the chain, and phases of buckets Now the overlay network only needs to worry about communication
Thoughts and Ideas? Interesting ideas incorporating a DHT network with blockchain to create an efficient overlay network To re-join the network, both nodes must proof-of-work on specific information. This must be done in a timely manner because of the lifetime of the directory Re-joins are going to happen constantly due to node lifetimes
