4 Matching Annotations
- Apr 2024
-
Local file Local file
-
The consensus is reached in the same way as fortransactions i.e. using hasgraph consensus algorithm. The onlydifference is, that the concerning events in the hashgraph nowcontain other type of data instead of transactions
Not necessarily, how to store
received events is an implementation detail. One could dump them in an array on a side. Can be as efficient as array of pointers to events. Where idx of this array is event's position in total order.
-
-
-
The use of a DAG-like structure to solve consensus has been introduced in previous works,especially in asynchronous networks. Hashgraph [ 4 ] builds an unstructured DAG, with eachblock containing two references to previous blocks, and on top of the DAG, the miners runan inefficient binary agreement protocol. This leads to expected exponential time complexity
Hashgraph's voting complexity is exponential. ?
Tags
Annotators
URL
-
-
arxiv.org arxiv.org
-
The block content isa pair 퐶 = (푣, 푃) of an arbitrary value 푣 (the block payload)and a set 푃 of the block identities of the predecessors of 푏
Since signature carries ID, referring by hash will not capture ID, wheres referring by ID will. Interesting approach.
Tags
Annotators
URL
-
-
github.com github.com
-
I think this would modify your trust model. Say you trusted 10 peers. If one of them was malicious, then you have 1/10 malcious peers and the majority of nodes are good so you could identify the bad node. In the changes you propose, (if I understand correctly), the 1 malicious node, could then send you 100 more malicious nodes. So then you'd be connected to 101/110 malicious peers and the malicious peers would be the majority.
A way to cater for eclipse attack can be to capture node's addresses in a hashgraph of that gossipsub topic. This way, when a new node connects to any of behaving peers, it'll get HG with addresses of others.
That will possute HG with unrelated to domain stuff however.
-