fix(docs): correct syntax on JSON-RPC eth_sendPrivateTransaction example

[BLLCrypto]

If you actually run the example code it doesn't work, you need to use "hash" instead of "transaction_hash" if you wanna hint it

[sarahalle]

Thanks for submitting this proposal @bigsky77! We are reviewing it and will get back to you with any questions

[bigsky77]

Hi @sarahalle - any updates on this? Thank

[jopasserat]

Thanks for your very interesting submission! At that stage, the present format lacks a real innovation that we would be interested in funding. The two main issues with your proposal are: 1) an outdated view of SGX and TEEs in general 2) a lack of exploration of the literature / related work. Below a more detailed view of the comments above and some pointers to help you revisit your proposal should you be interested in taking it to a different direction.

Outdated view of SGX and TEEs

• most of the FRP is based on a somehow outdated view of SGX, with a low amount of memory and high overhead. This depicts the first version of SGX which indeed showed these limitations, but most commercial TEEs have now transitioned to a cloud-first technology in order to lift these barriers and have now access to large enclave sizes and low overhead as you can see from our latest work with Intel TDX for instance

• you can check our wiki for a quick refresher of what's possible with modern TEEs https://collective.flashbots.net/t/tee-wiki/2019

• some of our other work in TDX can be reused for your project, as you can see we're running a whole block builder in TDX at near native speeds

  • https://collective.flashbots.net/t/building-secure-ethereum-blocks-on-minimal-intel-tdx-confidential-vms/3795
  • https://collective.flashbots.net/t/searching-in-tdx/3902

Related work on proving in SGX

• there are at least two pieces of work that we are aware of that cover the scope of your current proposal
• you can find an example of running espresso systems' implementations of plonk and hyperplonk in sgx using the Gramine LibOS
  • see https://github.com/DecentralizedSysGroup/zkTEE
• another project also has a demo of running a fibonacci example on SP1 in SGX with gramine (not public yet but will try to link it here once it is)
• the important thing is that it's not very hard with today's tools and modern TEEs to run a prover in a TEE, what's hard is to:
  • minimise the TCB
  • identify and prevent side channels

What could be promising

If you're interested in revisiting this proposal, here are some alternative ideas that would be more appealing.

Use case focus

• run prover in TDX with a minimal TCB and demonstrating how it unlocks multi-party use cases
  • private validium
  • coSNARKs w/ applications to DarkPools like Renegade.fi for instance
  • a potential source of inspiration https://github.com/orgs/noir-lang/discussions/6289

Security focus

• explore and demonstrate how to exploit side channels when naively running a prover within a TEE
• minimising the TCB of a prover running in SGX via Gramine or a TDX

Performance focus

• one element that would be interesting is the idea of natively porting a SNARK prover to SGX, but since we can do that relatively easily w/ Gramine and even more w/ TDX, 1) we would need to demonstrate significant performance gains to make it worth it 2) if we were to do that properly, taking into account controlled channels for instance, the overhead would however most likely be huge
• explore a CPU-GPU TEE co-design, either via something like Slalom, or NVIDIA H100

[bigsky77]

Hey jopasserat thanks for the super thorough feedback. I will digest, update, and resubmit. :)

[sarahalle]

Hi @bigsky77- I'm closing this proposal due to inactivity. Please resubmit an updated proposal if you would like us to review it later on