Advertisement
Guest User

Untitled

a guest
Jul 12th, 2018
1,025
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.53 KB | None | 0 0
  1. I had a conversation with Eric Hop and a few others in #tanglemath some time ago and we came up with an idea about how to potentially create a completely decentralized milestone consensus mechanism. Essentially the idea is that every node in the system could come to consensus about which transaction is considered a milestone without the existence of a coordinator(s). However, the idea is incomplete and i am posting here in hopes to understand why it cannot work or maybe develop it into a more complete idea.
  2.  
  3. First, we need to understand exactly what a milestone is and what it's requirements are. A milestone is simply a transaction/bundle and every transaction that it references is immutably confirmed, this means that a milestone cannot have a conflicting history. Milestones serve as the entry point for the Trunk and often also Branch transactions when running the walk. They should always be considered confirmed, and they should always reference the most recent previous milestone whether it be directly or indirectly.
  4.  
  5. • A valid bundle
  6.  
  7. • History is not conflicting
  8.  
  9. • Entry point for Trunk and potentially Branch
  10.  
  11. • Confirmed
  12.  
  13. • Always reference the previous milestone directly or indirectly.
  14.  
  15. Most of this is fairly simple. The difficult part is how to ensure that every single node in the network/cluster agrees simultaneously on which bundle is a milestone. Currently, milestones are signed and issued by the coordinator which is maintained by the IOTA foundation. This works on a small scale but ultimately cannot scale up to the capacity that the network would require in the real world. This also introduces an aspect of centralization which is obviously not desired.
  16.  
  17. The idea that was cultivated in my mind removes any trusted authority from the equation and allows the network to organically reach consensus on what transactions are considered milestones.
  18.  
  19. Every node listens for every transaction hash or maybe even bundle hash and when a certain string of character is discovered that bundle is flagged as a potential milestone candidate. If it passes the tests it becomes a milestone. Example, every node listens for a bundle hash containing this sting of characters: “ABCVIDSOQYEGHBF9QHOQNDUFAQ” (this is arbitrary). Once a bundle is discovered with that string it goes through some checks. Is it valid? Is the history non-conflicting? Does it reference the previous milestone? And possibly a timer would be needed to prevent milestones from occurring too frequently so, has 5 minutes gone by since the last milestone?
  20.  
  21. Some of these requirements are already taken care of as a result of the protocol itself. Validating a bundle is trivial. The random walk should ensure that the transaction has no conflicting history (though this would need to be checked by each node just in case). Using milestones as the entry points for the random walk should ensure that they are always confirmed as well as ensuring that the new milestone will most likely reference the previous milestone.
  22.  
  23. There is also the possibility that two or more transactions with the necessary string of characters can occur at almost the same time in this scenario we can introduce some extra checks so that when a second transaction is discovered before the other one is solidified as a milestone we simply wait until the network picks one over the other by choosing the one with the higher cumulative weight and or confirmation threshold. Also worth mentioning is that in this scenario the network would need to have a sufficiently high tps in order not to depend completely on milestones for confirmation so milestones could occur at a slower pace in order to resolve any conflicts. They would most likely be used as a starting point for the random walk, a reference point for self snapshots and maybe an extra precaution against double spends and other tricky attacks.
  24.  
  25. Syncing may be a bit of an issue here however. Another issue would be ensuring that all of the nodes agree. Maybe this could be achieved with a quorum. Every node participates in a coo assembly composed of 100 nodes per assembly and once each assembly reaches a quorum it publishes it's result to a Qubic that listens for every assemblies answers and reaches it's own quorum which then every node accepts? idk just a thought.
  26.  
  27. This is just a rough idea and I know the IF is working on some other coo removal research but I am curious to hear your opinions why this may or may not be feasible. If you have ideas how to improve this or why it is impossible or other requirements for milestones that i may have missed please comment.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement