multi-chain bottom-up consensus model prototype

[synctext]

Research superior consensus models, resilient against 51% attacks.

Create an operational prototype of a mechanisms which spreads the last known record of all multi-chain.

• All peers crawl to some extend
• They create 1 Bittorrent swarm with a database dump of all these records and seed it
• Download a swarm with records from the nearest neighbor
• Merge, double spending check, and remove duplicates
• Together with this neighbor, form a group, seed your unified database dump
• Repeat with exponentially increasing group size

[kc1212]

The idea of merging shares some similarities as the GHS MST algorithm. But unlike the GHS algorithm, bottom-up consensus needs to work in a dynamic environment (multichain is always changing) and also under churn, so that is a challenge.

[synctext]

Please read some related work:

• The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication
• Difficulty control for blockchain-based consensus systems
• The Sleepy Model of Consensus
• Hybrid Consensus: Efficient Consensus in the Permissionless Model
• SCP: A Computationally-Scalable Byzantine Consensus Protocol For Blockchains
• Enabling Blockchain Innovations with Pegged Sidechains

My advise would be to do a boring incremental steps approach, learn what you need to solve :

• get live edges operational
• get TrustChain edges from neighbor and pack into a single file
• publish all edges in a .torrent, broadcast hash to neighbor and download all neighbors
• join and merge operation on two files
• etc.

[synctext]

Currently the closest related work to Delft blockchain (MultiChain,TruchtChain): "THE SWIRLDS HASHGRAPH CONSENSUS ALGORITHM: FAIR, FAST, BYZANTINE FAULT TOLERANCE"

It is also graph-based, instead of a single chain. They provide an amazing polished description of the idea we call "offline voting", they describe as gossip-about-gossip. Their patented technology uses a graph-based blockchain and mentions a HashDAG. Uses proof-of-stake and single-party signed messages.

Corda is also transaction focussed. However, they lack a gossip mechanism. Transactions are listed on a chain, but stored in "vaults": http://r3cev.com/s/corda-introductory-whitepaper-final.pdf

[synctext]

Brainstorm outcome, detailing the three algorithm phases per round:

• consensus on ordered merge candidate list
• consensus on group merge
• consensus on group outcome

Using a commitment scheme we can generate guesses, winner becomes temporary elected leader for coordinating group consensus. Drawback: we don't like leader dependancies, DDoS vunerabilities, and failure/resume problems. Kelong: proof-of-luck

[devos50]

Just came across this consensus algorithm, might be interesting to read: https://www.stellar.org/papers/stellar-consensus-protocol.pdf

[kc1212]

The main disadvantage, also mentioned in the paper, is that the quorum intersection cannot only contain faulty nodes. This requirement depends on the assumption that the individual nodes to choose good quorum slices. In the application of Stellar it is reasonable, because nodes represent banks or other organisations. But the same isn't true for Tribler. Nevertheless, the idea of Federated Byzantine Agreement is very interesting.

[Zhijieren]

I will spend some time on this in the coming months.

[kc1212]

I'm currently writing up my idea, expect something by the end of the week.

[synctext]

First write-up by Kelong: bottom-up.pdf

[kc1212]

Updated my write-up with some negative results and my reasoning, see "2.5.1. Merging consensus groups does not guarantee BFT with a probability of 1"

bottom-up.pdf

[kc1212]

Create a repository for my thesis work, which contains the pdf. It'll be a bit unstructured in the beginning, just me writing ideas and results down. Hopefully it'll converge into a proper thesis by summer.

New section since last time - "2.5.2 Tail bounding the number of Byzantine nodes in a consensus group"