Skip to content

Releases: tlsnotary/tlsn

v0.1.0-alpha.12

19 Jun 13:49
f2ff4ba
Compare
Choose a tag to compare
v0.1.0-alpha.12 Pre-release
Pre-release

Notary Server

Clients can now authenticate to the Notary Server using JSON Web Tokens (JWTs) in the Authorization: Bearer header.

Benchmarking

A new, enhanced harness CLI lets you benchmark the TLSNotary protocol under configurable network conditions—both in native and browser environments. See the harness README for details.

Mutual TLS (mTLS)

Standard TLS only verifies the server’s identity to the client. In compliance-sensitive environments, servers often require clients to authenticate via X.509 certificates. Now the Prover (acting as a TLS client) can present a client certificate during the TLS handshake.

Performance

Added several MPC optimizations to reduce the overall runtime of the protocol.

What's Changed

🚀 Features

⚙️ Miscellaneous Tasks

Full Changelog: v0.1.0-alpha.11...v0.1.0-alpha.12

v0.1.0-alpha.11

27 May 18:00
878fe7e
Compare
Choose a tag to compare
v0.1.0-alpha.11 Pre-release
Pre-release

Core API Changes

Up until now our core APIs tlsn-(prover/verifier) and examples have placed an emphasis on the issuance of attestations, i.e. "notarization". We've begun the process of decoupling our attestation model from these APIs, starting with placing a deprecation warning on the corresponding methods. All attestation related functionality will be pulled out into a dedicated crate in a future release and notarization will no longer be provided by the core APIs. Instead, the core APIs can continue to be used to generate commitments and proofs which are used to construct attestations. In fact, if you look at how it works in this release you can see that building an attestation is quite simple.

These changes are intended to simplify the core API, increase flexibility, and also to highlight that using our particular attestation model is optional! Perhaps your application would prefer to issue attestations in the Verifiable Credential model instead? Or perhaps you want an even simpler format to integrate with a smart contract verifier. Maybe your application doesn't need attestations at all!

Transcript Hash Commitments

This release delivers transcript hash commitments (#881), starting with SHA256 with additional algorithms on the way including KECCAK256 and BLAKE3. It is now possible for the Prover to prove the hash of transcript data to the Verifier (which can be included in attestations). These commitments can be obtained using the existing TranscriptCommitConfig API, selecting the TranscriptCommitmentKind::Hash { alg: HashAlgId::SHA256 } commitment. Opening these commitments is simpler than the existing available "encoding" commitments, and should be significantly more performant.

Note: The now-deprecated notarization methods in the core API do not allow the Prover to commit to subsets of the transcript using hash commitments, only the entire transcript. This is to maintain the existing oblivious property of the reference Notary. In order to obtain hash commitments to the transcript the Notary would have to learn the indices of the data that are being committed, which themselves can leak sensitive information. The rest of the core API places no such restriction on commitments.

Performance

#735 introduced an optional mode which optimizes for low bandwidth connections between the Prover and Verifier. It offers a bandwidth/latency trade-off which reduces the amount of data uploaded from the Prover to the Verifier in MPC-TLS. This mode can be enabled with the ProtocolConfigBuilder::network method (NetworkSetting::Latency). When available bandwidth is on the order of 10Mbps this mode can reduce total proving time as illustrated in the figure below. However, it should be noted that this mode can cause reduced performance in higher latency (>50ms) settings or even in low latency settings where bandwidth is not a constraint (1Gbps). In the future we will look at providing a NetworkSetting::Auto mode which probes the connection and selects the optimal setting.

Putting aside the above optional mode, this release provides overall performance improvements and reduced latency sensitivity.

Notary server

The notary server now starts without specifying a configuration file. If you want to use a custom configuration, you can still provide a config file path on the command line or set the relevant environment variables. For most users—especially for test or development instances—no changes are needed, and it's now even more convenient since signing keys are generated automatically at startup. If you are running in production, however, make sure to provide your own keys and configuration as appropriate. For details on configuring the server, see the updated README.

Additionally, the Dockerfile has been updated to use an explicit entrypoint. If you are running the notary server in Docker, you may need to update your deployment scripts or configuration to accommodate this change.

What's Changed

🚀 Features

⚙️ Miscellaneous Tasks

New Contributors

Full Changelog: v0.1.0-alpha.10...v0.1.0-alpha.11

v0.1.0-alpha.10

18 Apr 12:05
de7a47d
Compare
Choose a tag to compare
v0.1.0-alpha.10 Pre-release
Pre-release

Alpha.10 brings a handful of changes including new features, improved error messaging and API simplifications.

Attestation Extensions

Attestations can now be extended with custom extensions to support application specific requirements. Both the Prover and Notary can be configured to include custom data. For example, a Prover could include their public key in the attestation to bind it to their identity. This has a number of potential uses during presentation to an attestation Verifier.

See the API docs for additional information.

Note: Even though the core Notary API supports adding extensions, currently the Notary reference server we provide can not be configured to include them without modifying its source and compiling yourself yet. Expect this to become possible in future releases.

Transcript Proof API

The TranscriptProofBuilder API has been further simplified to automatically select the best commitments to open without specifying this explicitly. As we add support for additional transcript commitment types this will remove some burden from our users while building transcript proofs.

Notary Server Concurrency Limit

Previously the Notary server would accept an unbounded number of concurrent notarization requests from provers. The Notary server can now be configured to limit resource utilization and mitigate potential DoS attacks.

What's Changed

🚀 Features

⚙️ Miscellaneous Tasks

Release artefacts

Build log: build
Full Changelog: v0.1.0-alpha.9...v0.1.0-alpha.10

v0.1.0-alpha.9

25 Mar 13:22
328c2af
Compare
Choose a tag to compare
v0.1.0-alpha.9 Pre-release
Pre-release

Alpha.9 brings focused improvements to the reveal API and transcript construction, along with important bug fixes following alpha.8. This release reflects our shift toward faster, more frequent iterations — helping us build momentum as we head toward the end of the alpha phase and work towards version 1.0.

What's Changed

🚀 Features

  • Find set cover solution for user in TranscriptProofBuilder (#664)
  • Ethereum compatible signer (#731)
  • Make logging format configurable by @LogvinovLeon (#719)
  • (notary) Build notary and publish docker image for dev branch(#726)

🐛 Bug Fixes

  • Record layer handshake control flow (#733)
  • Compute recv record count from max_recv (#743)

⚙️ Miscellaneous Tasks

  • refactor: migrate to rand 0.9 (#734)

New Contributors

Release artefacts

Build log: build
Full Changelog: v0.1.0-alpha.8...v0.1.0-alpha.9

v0.1.0-alpha.8

07 Mar 23:52
Compare
Choose a tag to compare
v0.1.0-alpha.8 Pre-release
Pre-release

Highlights

The main highlight of this release is the MPC-TLS upgrade (#698) which swaps out our MPC and ZK backends to incorporate the latest work in mpz. Most prominently, we now use the VOLE-IZK Quicksilver protocol instead of Garbled Circuit ZK. This provides a significant reduction in bandwidth utilization. Additionally, we've incorporated many control flow optimizations which have reduced the online time by up to 96% compared to previous releases.

Performance Changes

Latency

As mentioned above, we've introduced a handful of control flow optimizations which have reduced the round complexity of our implementation. The figures below illustrate the effect of latency between the Prover and Verifier (Notary) with a 1Gbps connection. Notably, online time is now much less sensitive with respect to latency. This should resolve any TLS server timeout issues users were experiencing.

Bandwidth

Online time is now essentially invariant with respect to bandwidth, which again should eliminate most time out issues one may have experienced on slower connections. Total time has been reduced by approximately 50% across the board when holding latency constant at 50ms. Upload bandwidth is now the dominant factor in total proving time.

What's Next?

Regarding performance, we are approaching the theoretical limit for MPC-TLS dictated by the TLS PRF MPC cost (barring breakthroughs in MPC 😉). We have another optimization we will implement which reduces the upload size for computing the PRF by approximately 2/3 at the expense of increased latency sensitivity. This will reduce proving time by roughly the same factor, as it is the dominant cost. It will be available as a configuration option for when latency conditions are appropriate. We also have our eyes on some improvements to our WASM build to reduce CPU cost and bring it closer to native performance.

Aside from that, our focus will be turning towards features and tooling to support a wider range of use cases and improve developer experience. See the issue tracker for what's ahead, and feel free to open issues for feature requests!

What's Changed

🚀 Features

  • (notary) Support reading config values from CLI and env var (#605)
  • (notary) Intel-sgx attestation

🐛 Bug Fixes

  • (notary) Fix client issue of not being able to specify the notary url path (#614)
  • (notary) Implement timeout for notarization (#639)
  • (notary) Make TLS keys and authorization whitelist configs optional (#589)

⚡ Performance

  • MPC-TLS upgrade (#698)
  • Compress partial transcript (#653)

⚙️ Miscellaneous Tasks

  • Generate coverage report
  • Add core transcript unit tests (#649)
  • (notary) Update axum to v0.8 (#681)
  • (notary) Fix TEE deployments (#686)
  • (notary) Improve notary server html info (regular and TEE)
  • (notary) Calculate SGX mr_enclave for notary server in gramine docker (#701)
  • Bump deps (#704)
  • Removed unused dependencies (cargo machete)
  • Re-added explicit getrandom dependency in the wasm crate (#646)
  • Update wasm-bindgen and wasm-bindgen-rayon dependency (#662)

New Contributors

Full Changelog: v0.1.0-alpha.7...v0.1.0-alpha.8

v0.1.0-alpha.7

03 Oct 22:10
4d5102b
Compare
Choose a tag to compare
v0.1.0-alpha.7 Pre-release
Pre-release

Highlights

The main feature of this release is a rewrite of tlsn-core summarized below:

  • Improved the structure of attestations
    • Header has a static smol size and now includes a version tag and unique identifier
    • Body fields are now merkelized so that only fields necessary to prove desired statements need to be included
    • Body is forward-compatible with new kinds of fields (for example, new kinds of commitments)
  • Added a Request pattern which will allow a Prover to configure aspects of the attestation depending on what the Notary supports.
    • This paves the way for custom extensions, eg #342
  • Further encapsulated various kinds of proofs
    • ServerIdentityProof proves the server name using the certificate chain
    • AttestationProof proves the Notary signature and attestation body
    • TranscriptProof proves subsequences of the transcript using the encoding or hash commitments.
  • Extensible cryptographic algorithms via CryptoProvider (inspired by rustls).
    • Added keccak256 and sha256 to officially supported, including user provided custom algorithms.
    • Added secp256k1 signatures, including user provided custom algorithms.
  • Added a new PlaintextHash commitment type (not fully exposed yet) which will be implemented with authdecode. See #479
  • Encapsulated more logic into this crate in the form of builders, reducing API surface area and making it more difficult to misuse.

We are open to requests for adding more officially supported algorithms, please open an issue. We already plan to add Poseidon hashes with popular parameters, such as being circomlib compatible.

Check out the API docs!

In addition to the tlsn-core rewrite there are numerous stability, error handling and ergonomic improvements. Including consolidating all our crates into a single workspace, which improved compile times.

What's Changed

🚀 Features

  • (tlsn-wasm) Wasm bindings (#536)
  • (wasm) No-bundler flag (#546)
  • Add protocol configuration negotiation (#513)
  • Make defer-decryption default
  • (wasm) Clone getters (#600)
  • (wasm) Expose presentation verifying key

🐛 Bug Fixes

  • Miscellaneous fixes on documentations (#528)
  • Clippy gh action and linting (#531)
  • Notary cd (#538)
  • Correct paths following repo reorg (#554)
  • Repair wasm build. (#567)
  • Check if already committed in commit (#568)
  • Aead unit tests no longer deadlock
  • (wasm) Attestation.deserialize should return Attestation (#597)
  • (verifier) Correct error display (#599)
  • Clippy fix too_long_first_doc_paragraph in enum_builders
  • (core) Remove serde flatten
  • (wasm) Remove presentation verify from test
  • (examples) Fix examples for alpha.7 release (#603)

🚜 Refactor

  • Consolidate workspaces (#537)
  • Modularize server-fixture (#563)
  • (core) Alpha.7 rewrite (#574)

📚 Documentation

  • Fix links in README.md (#544)
  • Fix and improve interactive example (#552)
  • Describe execution modes (#464)
  • Fix typos (#569)
  • Added note about "format on save" to the contribution guide
  • Add section about linting to contribution guide
  • Rustfmt wrap_comments (#611)
  • (core) Additional documentation and examples (#613)
  • Correct foldername in examples readme (#624)

⚙️ Miscellaneous Tasks

  • Add check to identify number of stable versions deployed (#532)
  • Cleanup after workspace consolidation
  • Extend tls certs perpetually (#555)
  • Temporarily disable deadlocked tests in aead (#547)
  • (examples) Remove examples, fix bug (#585)
  • Add favicon to wasm-test-runner to avoid 404 in tests
  • Run test with debug logging, not the build
  • Remove clippy::blocks_in_conditions (#592)
  • (notary) Change fixture pub key to compressed form (#623)
  • Prepare alpha.7 release (#620)
  • Core-rewrite unit tests (#608)

New Contributors

  • @valo made their first contribution in #592

Full Changelog: v0.1.0-alpha.6...v0.1.0-alpha.7

v0.1.0-alpha.6

26 Jun 14:24
3554db8
Compare
Choose a tag to compare
v0.1.0-alpha.6 Pre-release
Pre-release

This release includes performance and stability improvements, as well as preparation work for future upgrades.

Unfortunately, the long-awaited Authdecode feature is not included in this release (sad trombone noises). However, we plan to release updates at a faster pace, so it will land soon™. Join our next office hours event to hear more about our priorities and what's next.

Highlights

mpz Upgrade

We have made significant improvements to mpz, the MPC library used by TLSNotary. This release includes enhancements to the handshake/online time of the protocol, reducing online time by up to 30% on higher latency connections, which should help alleviate server timeout issues. More improvements in this area will be included in future releases, supported by further upgrades to mpz.

GHASH Update

We've updated the 2PC-GHASH protocol so that the Prover no longer needs to reveal the MAC keys to the Verifier after the TLS connection is closed to perform consistency checks. This key revelation step was shown to be unnecessary by PADO in their Lightweight Authentication of Web Data via Garble-Then-Prove paper, demonstrating that semi-honest OLE is sufficient. We thank PADO Labs for their discussion and collaborative spirit.

Notary Client

We have added a client implementation in #489, which simplifies interacting with our reference Notary server. It handles the low-level details of setting up a notarization session, allowing developers to focus on their applications.

What's Changed

⛰️ Features

  • Add notary client crate (#489)

🐛 Bug Fixes

  • (tlsn-server-fixture) Update cert fixtures (#499)

🚜 Refactor

  • Restructure notary crates (#508)
  • (universal-hash) Mpz upgrade (#502)
  • (key-exchange) Mpz upgrade (#496)
  • (cipher) Mpz upgrade (#501)
  • (prf) Mpz upgrade (#497)
  • (prf) Relax hiding of transcript hash, optimize latency (#505)
  • (aead) Mpz upgrade (#504)
  • (tls-mpc) Mpz upgrade (#511)
  • (tlsn) Mpz upgrade (#512)

📚 Documentation

  • Miscellaneous fixups (#475)
  • Fix style issues (#476)
  • Fix style in components (except TLS) (#477)
  • Update CONTRIBUTING.md (#483)

⚙️ Miscellaneous Tasks

  • Refactor and improve CI build (#486)
  • Update notary certificate (#519)
  • Add rebase action (#515)
  • (uid-mix) Delete crate, moved to tlsn-utils (#506)
  • Remove stale test and clean up CI job (#514)
  • Update CI configuration
  • Bump mpz version

v0.1.0-alpha.5

09 Apr 17:00
68b9474
Compare
Choose a tag to compare
v0.1.0-alpha.5 Pre-release
Pre-release

This release delivers performance improvements, bug fixes, and updates to our example documentation. We've opted to release these enhancements early to support our community in time for the ETHDam hackathon.

The AuthDecode PR is scheduled for inclusion in our next release. This decision allows us to expedite the current update, ensuring you have access to the latest improvements as quickly as possible.

Highlights

Transcript Size Configuration

Independent limits are now set for the sent and received data transcripts. This adjustment allows for more precise specification of expected data volumes and complements the record layer preprocessing described below.

Record Layer Preprocessing

The MPC-TLS protocol now preprocess the MPC for the sent data transcript, adhering to the configured sent data transcript limit. This enhancement shortens connection times with the server and helps mitigate timeouts.

The default sent data limit is 4KB, but it can be adjusted to accommodate larger HTTP requests or reduced to minimize overall proving time. For configuration options, see ProverConfigBuilder and VerifierConfigBuilder (make sure their settings match!).

Interactive Verifier Example

Explore the interactive verifier example to utilize the protocol's "trustless" configuration, which omits Notary attestation and directly proves data to the Verifier.

What's Changed

Full Changelog: v0.1.0-alpha.4...v0.1.0-alpha.5

v0.1.0-alpha.4

13 Feb 19:18
309c37f
Compare
Choose a tag to compare
v0.1.0-alpha.4 Pre-release
Pre-release

Highlights

This release contains new features, performance optimizations, bugfixes and, of course, breaking changes!

Interactive Verifier

This release introduces support for directly proving the server identity to the MPC-TLS verifier and selective disclosure of the transcript. This configuration is important as it is the "trustless" variant of the protocol which does not rely on a third-party attestation (from a Notary).

Examples and additional documentation are coming soon™

Deferred Decryption

The new deferred decryption feature is one to take a look at. It is an optimization which can be activated when server response data can be decrypted after the TLS connection is closed. For example, you can activate it before sending a final HTTP request to the server, and it will defer decryption of the response.

The benefit of doing this is two-fold:

  1. It significantly reduces upload bandwidth utilization from the Prover to the Verifier
  2. It reduces CPU utilization for both parties.

Both of which can lead to large reductions in the total runtime of the protocol, particularly for a Prover with an asymmetric internet connection to the Verifier.

An example of how to use this feature is demonstrated in the twitter example.

This feature paves the way for massive performance increases in the future when we integrate VOLE-based interactive ZK proofs. Unlocking the ability to prove data on the order of megabytes.

Selective Disclosure API

This release provides a simplified API for selective disclosure of HTTP and JSON data. The previous release provided a rather clunky builder style API for generating commitments and proofs for both formats. The new commitment API is closer to a "visitor" style, and provides reasonable defaults that should cover most use-cases so you don't need to implement it yourself (unless you want to). For selective disclosure you get to work with the format types directly.

Check out the twitter example to see it in action.

What's Changed

Features

  • Interactive verifier (#379) (#401)
  • Tls-client backend buffer (#414)
  • Deferred decryption (#416)
  • Network simulation benches (#417)
  • Default commit to entire http request/response (#433)

Performance

  • Adjust mux config (#418)

Bug Fixes

  • Use non_exhaustive instead of private zst (#428)
  • Prevent duplicate json array commitment (#432)

Documentation

  • Updated examples based on the Progcrypto workshop (#399)
  • Add style guide (#411)
  • Update Direction docs (#427)
  • Remove dead argument docs (#429)

Refactor

  • Use tls prf from tls-core in rc backend (#413)
  • Add AEAD prove/verify + tag methods (#415)
  • Tlsn-common mux module (#420)
  • Selective disclosure api (#380)
  • Update hyper and use http prover (#434)

Miscellaneous Tasks

New Contributors

Full Changelog: v0.1.0-alpha.3...v0.1.0-alpha.4

v0.1.0-alpha.3

21 Dec 11:39
bfc7078
Compare
Choose a tag to compare
v0.1.0-alpha.3 Pre-release
Pre-release

What's Changed

New Contributors

  • @0xvon made their first contribution in #363
  • @mhchia made their first contribution in #383

Full Changelog: v0.1.0-alpha.2...v0.1.0-alpha.3