EthCC 2 Daniel A Nagy Questions
Ethereum Paris·Wed, Oct 9, 2019, 12:00 AM
EthCC 2 EthCC, the Ethereum Community Conference is created by the community, for the community. It brings together great minds and forethinkers, and allows the community to grow. Follow us : @AssethFR https://ethcc.io
Transcript
sorry brother well I did not fully realize or understood how the act works who maintains the list and how is actually how did how this list works how are not disclosing neither yourself or who else is in this list and how do you verify that you're part of this list right so how does the act work so in last year's conference I gave actually a fairly detailed technical overview so if you can watch the video from my last year's presentation you will have a very detailed overview of how act works because that's when we present it how it will have been in how it will be implemented and now it's been implemented pretty much along those lines but the short answer is that the publisher of the content is the one who maintains the act so the act is basically a it's a file it looks like a file on swarm and it's the publisher who maintains it or you can use other act so acts are reusable as I mentioned and the way they work is that they are an encrypted key value database where the key is a difficulty crate beetween the grantee so the the person of the reader with the read access who knows the corresponding private key and the publisher which means that you know your own key in that key value database but you don't know anybody else's key because they're difficult secrets so this way you calculate the different shared secret and then you look it up in this key value database and if you find it then of course you have read access if you don't then you don't but you cannot check up on anybody else thank you there's a question here so my question is about the scalability of the DHT what's the limitation of that and is form gonna have some time after that limitation is reached the limit so the which one the DHT the DHT so so the DHT that we're using is a derivative of or a variant of Kadam Lea and so in academia network each node has a logarithmic so if the size of the network is n so we have n nodes in the network then each node has a logarithm and connections which is usually manageable so even if n is really large the number of connections that you need to maintain is manageable so that's not a scalability bottleneck the diameter of the network which means that the path the longest path along which data needs to be passed around is also logarithmic which is a little bit of a problem because if the network grows really large it will mean that these shortest paths will be logarithmic in the network of size which in terms of latency can be a problem across the network and the way swarm deals with it is by caching so actually caching is both implemented and incentivized so if you are a swarm node you actually gain from caching whatever passes through you and if there's some popular content it gets cached around the network so you don't actually need to go all the way down to the node that is closest to it because you will find it closer to yourself so caching is a big way in which we are trying to overcome the inherent limitations in the network that in the academy layer structure that we have and another limitation so another scalability limitation of Kadim lea is the fact that in the like the class tadam Leah you will need to constantly establish connections which are expensive so it's a it's a it's it's implemented over UDP and it needs to go all through all these not forward so not firewall penetration things and so on but that's the part where we change things a little bit so we we use more persistent tcp-based connections meaning that once you establish a connection you reuse it and because of that actually that part of scalability is not so much of a problem it brings up a whole host of other challenges and it's been the source the number one source of instability that you have seen in the test not so far but we are making good progress on that as well answers a question so did I get it right that the AC T's are a separate second Merkle trees in the system for access management first so a cities our manifests so they are very so it's the same data structure that we use for resolving paths into references so it's it's amortized data structure it's the same data structure as we use in the manifests and it's not the same data structure that we used for chunks so it's it's one of the two data structures that we use a cross form I'm particularly interested is that if you give me access in your a CT for a chunk of data does that mean that you have to leak leak logarithmic number of other of your peers who has access to that data because I have to reconstruct the route of the AC T so you need a logarithmic number of other appears to me no that's okay that's not the case because so the the AC T is a key value database where the keys are difficult and shared secrets so even though you do leak some data about those shared secrets but those are different shared secrets so as long as the decisional diffie-hellman assumption holds up you can do anything useful with with those with with that data it doesn't tell you anything about who has access okay thanks there's a question there okay okay thank you so much again [Applause]
Automatic transcript — names and jargon may be misspelled.