Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FaaS-compatible notary server #556

Closed
lijok opened this issue Aug 2, 2024 · 2 comments
Closed

FaaS-compatible notary server #556

lijok opened this issue Aug 2, 2024 · 2 comments

Comments

@lijok
Copy link

lijok commented Aug 2, 2024

Hi team,

We're exploring ways to host the notary server at-edge, so it's as close to the provers as possible. Couple of hosting options would involve writing a FaaS-compatible (say AWS Lambda) notary server. Specifically, making it stateful in a way that allows it to work without a persistent open socket to the prover (imagine it working just like an HTTP API for the notarization process).

Has the team played around with this or a similar idea in the past at all?
Is there any information you could provide us regarding what roadblocks we might hit if we attempted to implement a notary server with these semantics?

Thank you !

@sinui0
Copy link
Member

sinui0 commented Aug 3, 2024

The underlying MPC/IZK that is used in TLSNotary essentially requires a persistent duplex connection in practice. I can imagine you may be able to implement it over HTTP semantics but that would be with great effort and likely inefficient. The protocols have several stateful communication rounds and use IO multiplexing.

The implementation of TLSNotary (and its underlying mpz library) is tightly coupled to having persistent duplex IO. It would be a huge lift to rewrite it to support snapshotting the state on every round.

I feel the FaaS paradigm may be a poor fit for the task here. You will likely get better bang for buck pursuing a managed multi-region container solution which allows you to open persistent connections. Outside of a notarization session, the Notary server itself is already pretty much stateless. I don't see any hurdles for spinning them up and down on demand to save on costs.

In the near term (Q3), we're focused on improving performance and you can expect latency to become much less of a factor. Memory footprint and bandwidth usage will also be reduced significantly.

@lijok
Copy link
Author

lijok commented Aug 5, 2024

Thank you for looking into this @sinui0 - very useful context.

@lijok lijok closed this as completed Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants