# Reusable Enclaves

**URL:** https://collective.flashbots.net/t/reusable-enclaves/3694
**Category:** References
**Tags:** article, links, trusted-execution
**Created:** [July 21, 2024, 9:44pm UTC](https://collective.flashbots.net/t/reusable-enclaves/3694 "2024-07-21T21:44:22Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![socrates1024](https://collective.flashbots.net/user_avatar/collective.flashbots.net/socrates1024/32/1622_2.png) [@socrates1024](https://collective.flashbots.net/u/socrates1024)
#### Post date: [July 21, 2024, 9:44pm UTC](https://collective.flashbots.net/t/reusable-enclaves/3694/1 "2024-07-21T21:44:22Z")

</div>

This paper is really interesting. It can be seen as addressing the “credible conditional recall” problem in an SGX enclave, because it implements a rapid “snapshot” and “reset” functionality. It’s implemented as a virtual machine layer for running guest processes within an SGX enclave.

> **[Reusable-Enclave.pdf](https://bpb-us-w2.wpmucdn.com/u.osu.edu/dist/0/113190/files/2023/07/Reusable-Enclave.pdf)**
>
> 726.60 KB

 ![image](https://collective.flashbots.net/uploads/default/original/2X/6/6ed48ff14f7b0a13c99bddc7a73790d62b9211be.png)

There’s a lot of other insights on hardening too, including when running Wasm code compiled to native. @tolak

The implementation is summarized in this instructions page (other in forked version of other projects).

> **[GitHub - OSUSecLab/Reusable-Enclaves: Implementation of the Reusable Enclaves...](https://github.com/OSUSecLab/Reusable-Enclaves)**
>
> Implementation of the Reusable Enclaves paper. Contribute to OSUSecLab/Reusable-Enclaves development by creating an account on GitHub.

The paper is framed as about “serverless” functions, but my intended use would rather be to “clone” of a long-running program, getting a copy of its active stack/heap memory. But the paper seems to be about resetting to a nearly-initial state, so there isn’t as much to copy. I was hoping for something that worked like [copy-on-write](https://en.wikipedia.org/wiki/Copy-on-write) to get the best of both, so maybe that still remains open to try.

---

<div class="post-metadata">

### Author: ![tolak](https://collective.flashbots.net/user_avatar/collective.flashbots.net/tolak/32/2418_2.png) [@tolak](https://collective.flashbots.net/u/tolak)
#### Post date: [July 22, 2024, 12:08pm UTC](https://collective.flashbots.net/t/reusable-enclaves/3694/2 "2024-07-22T12:08:59Z")

</div>

@socrates1024 Really interesting cause Phala also reuses enclave in our Phat contract implementation, each worker runs an enclave instance and lives all the time to service multiple smart contracts execution. We don’t implement stack/heap memory copy too, only the contract state be updated to blockchain by the `transactions`. But indeed this is worth trying, from my previous development experience with our contract, I do struggle with writing stateless `query` logic (like the view function in Solidity which doesn’t change contract state) because only 10s is allowed to execute the `query` and always being interrupted, it would be great if we have stack/heap saved, things could be more complicated though in a distributed workers network.  
Another one is this paper also implements MLIEC for memory isolation inside an enclave and nested attestation, which is pretty inspired, we currently rely on WASM virtual machine for memory isolation, which theoretically needs trust assumption for their implementation

---

<div class="post-metadata">

### Author: ![mateusz](https://collective.flashbots.net/user_avatar/collective.flashbots.net/mateusz/32/336_2.png) [@mateusz](https://collective.flashbots.net/u/mateusz)
#### Post date: [July 23, 2024, 9:06am UTC](https://collective.flashbots.net/t/reusable-enclaves/3694/3 "2024-07-23T09:06:43Z")

</div>

I wonder if one-way container live migration, not across nodes but rather across sandboxes, would do the trick.
