You are viewing a single comment's thread from:
RE: Visionaries are stakeholders, traders are investors...
You a big fan of RLC vs say Golem? any big differences between the two?
You a big fan of RLC vs say Golem? any big differences between the two?
RLC (iExec) is to be built on top of a high quality middleware which is already written. So when they claim they'll have something ready by November I can look at the middleware code here: https://github.com/lodygens/xtremweb-hep?files=1
And based on the code see that their estimation is plausible, doable, practical. They don't make any impossible promises in their marketing like "unstoppable code" or anything ridiculous like "code is law", they make very pragmatic promises with realistic expectations. Then I look at the team at iExec and they have the people who are literally the most elite in distributed cloud computing. The founders of iExec are also the developers of XtremWeb-hep. So they have the academic credentials (doctorate degrees), and the code to analyze, giving them a clear track record. Most important of all, they are long time career professions with relationships with academia, government, big corporations, and even some crypto related companies like Genesis Mining.
I look at Golem, and Golem is developed by a team in Poland and I don't know much about any of them or their track records in distributed computing or cloud computing etc. They are also a lot more ambitious, make much bigger promises, have a more marketing based "big promises" approach which I'm skeptical of their ability to deliver on in any reasonable amount of time because it appears they are reinventing the wheel doing it all from scratch.
So from a technical point of view, I already am a little bit familiar with iExec. From a technical perspective, it's a simple project building on an established middleware created by the founders of iExec. Golem is a thesis in itself, and to me seems more like the thesis project of college students trying to learn how to build something new rather than the implementation project of established professors.
Besides differences in team, there also are technical differences. The purpose of iExec is to create an API so developers of smart contracts can make use of off chain computation. Ideally iExec will offer a decentralized market network for computation resources and offer a nice interface for cloud computing. Golem I'm not entirely sure if they are building an API but even i they decided to do it, there is no real reason why I would believe their API will match iExec particularly because iExec is focused on catering to developers primarily. Golem also seems to have more focus on distributed secure multiparty computation and less focus on cloud computing. There is a distinction though, because cloud computing implies virtual machine instances which can run on a remote machine being rented over a market network, while distributed computing seems to imply breaking up a computation and sharing pieces of it over multiple computers.
These are different use cases. A secure distributed computation is a lot more difficult to pull off. In the case they do pull it off, then the Golem network could become a provider for iExec. I favor the design of iExec because I look at Golem and they claim to want to do secure distributed computation over "isolated virtual machines" and I'm just not convinced of that approach. The best approach I saw was Codius https://www.codius.org/ , which allows for smart contracts via peer to peer open hosting. In my opinion this at least gives a clue to how to go about it, in that I don't think faith in the code and quality of the virtual machine should be the only mechanism to supply security for a "worldwide super computer", as I think isolation of software processes simply isn't going to be good enough, but what do I know? I'm sure they have people who can figure it out, this is a non-trivial approach.
Don't get me wrong here, the middleware of iExec in my opinion is not optimized. I look at some of the design choices as questionable with regard to performance. The choice of Java as the language, the choice of certain protocols, all have an impact on performance which I expect not to be very fast. This is a bottleneck in design which can be exploited by future competitors, just as EOS has a design advantage over Ethereum in performance.
But what they gain with choosing Java is a language a lot of developers know (familiarity). Also Java is an easy language to work with compared to C++, being that it is more forgiving. On the topic of security, again they choose a baffling certificate approach, which I guess on the face of it was/is okay but in my opinion not ideal or sufficient long term. I think we need to find a way to get away from trusted certificate authorities which can and have been compromised in the past.
I refer to this: https://www.vidder.com/compromised-ca-certificate-attacks/
References