iExec Dev Letter #7: Pre-V1 R&D — 04 Sep 2017
Welcome to the biweekly iExec development letter. We’ll cover our latest developments, recruitments, and share some research perspectives that we find very promising.
The team is growing
The team is getting stronger, and this month we’re welcoming:
- Wassim Bendella, who is joining iExec as a content producer, communication expert, community manager, and business developper. Wassim is editor and journalist at cointelegraph where he wrote several articles about Bitcoin, Blockchain, Ethereum, ICO, Bancor, and more.
- Hadrien Croubois, PhD student at ENS Lyon, will start a part time collaboration with iExec as a “scientific consultant”. This status allows French PhD students to provide SME with an expertise close to their topics of research. Hadrien will collaborate on the design and evaluation of the Proof-of-Contribution algorithms.
On going developments
Devcon is getting closer, and so does iExec V1 release! The product launch is scheduled for November 2017, and this is going to be a great milestone for us, …and for every Ethereum developer out there ;-) Oleg, Eduardo, Jorge, François and Victor are busy working on several developments. Here’s an overview of what’s going on.
- We are working hard on iexec-sdk, which is the most important part for V1. The SDK is composed of a set of smart contract, CLI tools to deploy your application on iExec, and documentation We plan to release iexec-sdk for the next devel letter, along with the first tutorial (HelloWorld).
- The generic API as well as the oracle are getting more and more complete. We are pleased to open-source the first version of iexec-oracle that can be cloned from GitHub.
- We have also released the first version of iexec-node. This includes XtremWeb-HEP binary distribution, documentation, docker and vagrant images, PoC (vanitygen and stockfish), as well as various utilities. You don’t need to run a iexec node, we’ll do that for you. However, if you really want to; now you can. Power is in your hands ;-)
- Another interesting development is the ability to login to iexec using your Ethereum address. Oleg is working on a Ethereum Webtoken authentication plugin that will allow users to authenticate using metamask for instance. In short, it means we’ll provide a multi-users, multi-applications environment with authentication provided by Ethereum signin. A premiere to our knowledge, and a feature needed for enterprise deployment.
- Delegation has been added to XtremWeb-HEP. This allows the oracle to interact with XtremWeb on the behalf of the smart contract invoker identity. This will be released very soon (XtremWeb-HEP-11.0.0).
- Victor is working on the iExec explorer. Think it as a sort of Etherscan for iExec. This is extremely important for developers, as it will allow them to trace off-chain computation.
Some research on Intel SGX ?
Have you heard of Intel SGX? Do you know what is an enclave? You should, because it’s the second enabler technology for the distributed Cloud. The first one being blockchain and smart contract of course ;-)
Intel Safe Guard Extension (SGX) is a set of processor instructions that Intel has added to its line of x86 processors. SGX instructions allows to define enclave. Enclaves are protected areas of execution in memory that protect the data and process execution from external access. It means that even higher-priviledged system — such as the kernel or the hypervisor — cannot access the application running within an enclave. And this is really new! Up to now, there was no mechanism that would prevent root to spy on data code. That this is the reason why you probably have bought a Ledger or Trezor hardware wallet, right?
Of course, it would be rather difficult for a developper to modify his own application so that it executes within an enclave. Instead, people are looking for solutions that would allow to execute transparently unmodified applications in a protected environment.
For instance SCONE [1], is a secure Linux container mechanism that relies on SGX to protect application shipped as Docker container. This is a very interesting approach for containers, as they provide lesser level of security compared with VM (attack surface is larger because they share the kernel with the host machine). I guess that you also get the potential of this solution for iExec. It means that a developper deploying his application on iExec+Scone would be sure that remote host would not be able to spy on his code and/or data! Nevertheless there are some technical challenges as explained by the paper recently published at OSDI’16. In particular performance overhead due the increased execution environment complexity: context switches, memory management (cache misses, pages swap), etc.
Minibox [2], is a two-way sandbox built using memory space isolation (TrustVisor, SGX). A two-way sandbox allows to : 1) protect the host from malicious application (viruses for example), and 2) protect the app from the guest OS (someone spying the data for example). Graphene-SGX [3] demonstrates that a fully-featured library OS can deploy unmodified applications on SGX with reasonable performance degradation. This also is an interesting perspective as libraries OS and unikernels allow for finer grain of deployment than container.
But the applicability of enclaves doesn’t stop here. Actually enclaves can be also used to improve protocols of distributed systems — blockchains included. For instance [4] reports on a byzantine fault tolerant protocol that relies on SGX to provide high-performance hybrid state machine replication protocol (1 million tx/sec on a 4 cores proc.). Another great example is Teechan [5], a channel payment implemented on Bitcoin that shows astonishing performances: 2400 tx/s and submillisecond latencies.
What do SGX and enclaves change for iExec (and also Truebit, Enigma, Plasma, Golem,…) ? Before, we couldn’t prevent a remote execution to be cheated by the resource provider (worker). Now, we can. So, does it remove the need for result certification, redundant execution, reputation, blacklisting, arbitrage court, PoS, etc. ? Not really. First because you cannot trust Intel, and we don’t know yet the attack that are feasible against SGX. And because wrong results are not necessarly due to malicious participants but can be simply computation errors because … errors happen (disk, memory bit flip, etc.), as we shown in [6].
Short bibliography
[1] Arnautov, S., Trach, B., Gregor, F., Knauth, T., Martin, A., Priebe, C., … & Goltzsche, D. (2016, November). SCONE: Secure Linux Containers with Intel SGX. In OSDI (pp. 689–703).
[2] Li, Y., McCune, J. M., Newsome, J., Perrig, A., Baker, B., & Drewry, W. (2014, June). MiniBox: A Two-Way Sandbox for x86 Native Code. In USENIX Annual Technical Conference (pp. 409–420).
[3] Tsai, C. C., Porter, D. E., & Vij, M. (2017, July). Graphene-SGX: A practical library OS for unmodified applications on SGX. In USENIX Annual Technical Conference, 2017
[4] Behl, J., Distler, T., & Kapitza, R. (2017, April). Hybrids on Steroids: SGX-Based High Performance BFT. In Proceedings of the Twelfth European Conference on Computer Systems Eurosys(pp. 222–237).
[5] Lind, J., Eyal, I., Pietzuch, P., & Sirer, E. G. (2016). Teechan: Payment Channels Using Trusted Execution Environments. arXiv preprint arXiv:1612.07766.
[6] Kondo, D., Araujo, F., Malecot, P., Domingues, P., Silva, L. M., Fedak, G., & Cappello, F. (2007, August). Characterizing result errors in internet desktop grids. In European Conference on Parallel Processing (pp. 361–371). Springer, Berlin, Heidelberg.
And finally, a surprise !
iExec and Pixelmatters are working hand in hand to the new web site since June. This is a long process, partly because the new web site will allow us to communicate about the fundementals of iExec, and we hope to give the world a clear message about the what the future of decentralized business will look like. At the moment, the design is done at about 70%, and implementation at 50%. We are confident that it will be ready shortly before the V1 release.
