You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 !
The text was updated successfully, but these errors were encountered:
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.
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 !
The text was updated successfully, but these errors were encountered: