|
Title: Low-Latency Restricted DAG Post by: likeatree on August 21, 2018, 01:42:46 PM Hello,
I have come with a tweak on directed acyclic graph blockchain structure which reduces latency. Basically, each user has their own personal blockchain "swimlane", and these chains are linked together temporally through witness hashes. There is no chance of un-intentional forking. You will still need to define a consensus function to deal with bad actors. If someone tries to attack by splitting their "swimlane" for example, consensus could choose the lane which has the most witnesses or just permanently ban them from participating in the ledger. Here's a basic idea of what I'm talking about: http://imgur.com/SOKHqAO A whitepaper. https://www.scribd.com/document/386713928/Restricted-DAG Please let me know what you guys think. Thank you! Title: Re: Low-Latency Restricted DAG Post by: aliashraf on August 21, 2018, 02:23:31 PM Thank for sharing. I Just read the introductory section of the white paper, very impressive, a deep understanding of blockchain and cryptocurrency
Let me finish reading it and will share my ideas regarding your(?) work. Title: Re: Low-Latency Restricted DAG Post by: monsterer2 on August 21, 2018, 03:34:44 PM https://i.imgur.com/E3qpe46.png In Figure 6, user A attempts to publish alternate blocks A2† and A3†. Since user B3 has already wit-nessed blocks A2, A2† would be rejected by all participants. Furthermore, A can be flagged as a malicious or compromised user for presenting two different solutions for A1 I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3. You need an objective way to sort this out. Title: Re: Low-Latency Restricted DAG Post by: aliashraf on August 21, 2018, 05:32:22 PM I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3. You need an objective way to sort this out. Title: Re: Low-Latency Restricted DAG Post by: monsterer2 on August 21, 2018, 05:39:55 PM I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3. You need an objective way to sort this out. That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3). 1) https://swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf 2) https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf 3) https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf Title: Re: Low-Latency Restricted DAG Post by: aliashraf on August 21, 2018, 07:23:09 PM I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3. You need an objective way to sort this out. That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3). Reminding that I have not fully digested this proposal, I wish you don't take my comments here as a personal judgment in favor of it. Yet for some reason, I'm positively biased toward shifting attentions from the sole consensus method a bit more to overlay network topology in crypto and blockchain techs. I mean it is so ridiculous we don't take care of this issue enough. Isn't it? |
