Grant proposal: Secret Tunnels

so, anyone developing on secret contracts has doubtlessly run into the following issues
1: major memory limitations/compute limitations
2: having to write in rust with complicated type setups even for simple data manipulation, with more complex datasci looking tough at best and impossible at worst.

I would, today, like to formally propose the project i’ve been back-and-forth thinking about for the past few months, which solves both of these issues: the Secret Tunnel SDK!

a spec for the SDK is below:

at a high level, the project would be an SDK for ‘wrap arbitrary python computation in a separate enclave, and use SN to verify that enclave contains what it says it does, and to send data safely to and from that enclave’.

What does this enable?
‘using numpy/scipy/sklearn/tensorflow on data via SN’, for one. For 2, all those wonderful decentralized lending algos that need floating-point arithmetic can now run on this. For 3, if you write your python computation idempotently, it massively decreases gas costs for expensive computations, and decreases load on nodes to run them. For 4, now you can have nondeterministic computations on SN via the secondary enclave! (only when the computation is idempotent/caches results)

What’s the deliverable?
A fully open-sourced set of build tools and secret contracts+templates to convert an arbitrary python program (within some size limits) into a Secret Tunnel-linked program on SN. Users should at worst need to docker-compose some prewritten dockerfiles. Obviously, all OSS, in case you need to change contract logic. If I can get enough money and a devops engineer, I’ll set up bare-metal cloud instances to run some number of enclaves internally – but the rest y’all might have to find separate hosting for (I’ll ideally include cloudformation templates/helm charts for spinning up ST enabled nodes).

What do I need to build it?
Enough money to justify me+a team spending however long it’ll take to get graphene running nicely and SN to play nice with graphene + SGX verification. After that, another coupla weeks or months to get the UX to the point of ‘as a tolerable python dev you can use this library’. Also ideally enough to pull in the aforementioned devops engineer + hosting fees. In total? Not sure, depends what y’all want/what unknown unknowns I’m missing. There’s a reason this is an informal proposal and not a formal ask yet.

Who am I?
Leor Fishman, currently taking a leave from harvard to build the web backend /cloud infra of a cloud computing startup, I’ve pretty much touched everything backend under the sun. Also I’ve been close with the enigma/SN team for 3.5 years and worked with them before.

Questions/Thoughts?

16 Likes

also, if anyone wants to work with me on this, BMG. Superfish is already tentatively interested

anyone who has ideas about how much they’d be willing to spend to fund this would be good, it’s a pretty extensive project but my prior funding experience is either contracting or VC-backed work.

This is a fundamentally important proposal.
Until now, we have always followed some trends :DeFi, swap exchange, etc. But Leor can open up some doors to unbeaten areas where we will be the trail blazers. it will open up an incredible universe of possibilities for the Network. I am very excited.

4 Likes

Questions

  1. How much funding do you want / need?

  2. What source of funding are you seeking funds from.

  3. Who are you working with?

Technical questions
You mention “ major memory limitations/compute limitations” as an issue on the secret network.

How might a future upgrade to the new SGX impact the current pain points highlighted here and usefulness if what you aim to build?

New sgx

2 Likes

how much: unsure, probably in the 5-6 digits for everything?
source of funding: grant fund, not community
Who I’m working with: rn just me + superfish
technical: SN has a pretty memory/compute limited runtime by protocol design, not sure Ice Lake will fix it, @assaf might know more

6 Likes

Thanks for clarifying. You and superfish sound like a good team to me. Will keep an eye in where you go with this.

2 Likes

This would open up a wide range of capabilities for Secret and ultimately make feasible many of the promising use cases we’ve all imagined.

It’s worth funding, and if the community needs to chip in I’d be on board.

Is there value considering the case beyond a secondary enclave? I’m thinking generalized to X enclaves, either locally or remote. Maybe MPI wrapped with with Secret magic to create a virtual SGX cluster?

3 Likes

mmmm, I’d prefer to leave stuff like that to future devs/future me? I’ll just label all the interfaces, anything that meets them could connect

1 Like

Yes, maybe better to leave for future work, but perhaps worth considering extensibility in design decisions.

oh, of course :slight_smile:

I have my eyes glued on this.

Questions I have:
These Secret Enclaves are provided by the user, right? Or is it the node runner who provides these extra enclaves for processing?

1 Like

My assumption was that the person building the particular use case would provide the tunnel enclaves – but, as mentioned above, with enough of a grant and the right devops person on staff (sideeyes @moonstash ) I could see running my own secret tunnel stack that someone could pay to upload code to/run on

5 Likes

A very interesting proposal.

I added some comments/questions in the doc file. To me, the main things missing/required are:

  • Stateful computations/chaining executions from SN and off-chain: Ideally, we can have ‘mixed’ contracts where some ‘cheaper’ executions happen on-chain, and more expensive ones happen off-chain. For this to work, the off-chain enclave needs to be able to take in current state data from the chain, and then attest to it as part of the output (which SN will further verify).

  • Incentives component - ideally, there’s a registry of such individual off-chain enclaves and the reason they are willing to do this is because they are incentivized to do so. On-chain, when a successful execution is verified, payment will be released.

  • Two years ago, Graphene was horrible. I know there have been efforts to improve it (inside the crypto space), but I don’t know how viable these solutions are. It may make sense to look at something more mature like Fortanix.

  • I would want to see a way to have more than one enclave execute these computations, to add a bit more security (something like a federated solution). This would make this proposal more interesting IMO, but would be harder to pull off (multi-sig/threshold sigs, determinism)

  • One final concern is safety. This is a bigger concern with something like Python, but I think it’s something we can live with to enjoy the other benefits (ease of use, cost and scale)

4 Likes

Thanks for the comments – I’ll think through statefulness/chaining for a bit on my own before coming up with a suitable abstract protocol for it (the answer might be some sort of compute subdivision, unsure) – incentives-wise I was actually assuming each enclave would be associated with one particular app, but if we were having multipurpose tunnels I agree we’d need an incentive solution.
Will look into graphene vs fortanix.
Imo safety is something you can verify on the individual program level – especially since these computations can be a lot more specialized since they don’t need to handle arbitrary transactions – I would be ok working in something like the pyodide stack so we could use WASM verifiers though :slight_smile:

Perhaps we could consider formalizing these tunnels to give SCRT income streams to the sub-50 tier validators. As in, until you’re top 50, you’re available for tunneled SGX compute, by default. In essence these nodes have indicated they’re interested in being a part of Secret computation, so it seems natural to extend that computation to the tunnels.

As Secret grows, the top 50 Validator list will become increasingly unobtainable. I already have more SGX hardware than I’m planning to deploy. And we’re all early here.

2 Likes

@Avret this is a really exciting idea!!

I’ve read through the doc and all of the comments from Reuven and Guy. Are you planning on addressing those in the doc itself? That would be great. I’m really interested in your answers!

Also, for those of us that do better with visuals ;-), any chance of including a dynamic diagram of the components and interactions? And maybe more of description in layman’s terms? It’s highly technical and reflects your brilliant mind, but it’s a little hard to read/digest (K_e, A_a, C_s, A_i). Maybe just naming the contract(s) and messages involved using more human wording? :smiley:

3 Likes

I’m planning to do both, yep :slight_smile:

2 Likes

This is a great idea, I wish you success.

1 Like