Hot take on Aptos vs. Arc vs. Canton confidentiality

tl;dr: A hot take is an incomplete, highly-opinionated, potentially-controversial take. Here, I give one on three different approaches to confidential payments (and beyond).

Aptos

• Good: Encrypts balances under the owning user’s encryption key $\Rightarrow$ no one can see the balance, except the owning user; not validators; not full nodes; not attackers who break into them.
• Good: Encrypts transferred amounts under the sending and receiving users’ encryption keys $\Rightarrow$ same guarantees
• Bad: Auditing functionality is somewhat restricted
  • Although governance-based auditors get full visibility into transferred amounts and encrypted balances¹, this is only after auditing is enabled.
  • Retroactive auditing of previous transferred amounts is not possible. (This is a good or a bad thing, depending on whom you ask.)
• Bad: Trickier to implement key management for users inside wallets $\Rightarrow$ must do extra careful cryptographic work to enable seamless confidentiality UX in wallets like Petra
  • Banks/customers may not like this, especially if they are clueless about blockchains
• Bad: 30x higher gas cost than public payments. (See gas benchmarks here.)

If confidentiality is what you care about most, go with Aptos. If it is full privacy, of course, go with Zcash.

Canton

I understand that Canton was built for permissioned enterprise networks where participants are known and regulated. Thus, operator visibility is viewed not as a bug but a feature for compliance.

• Bad: User’s balances are stored in plaintext on their chosen validator/operator $\Rightarrow$ that operator/validator can see the balance $\Rightarrow$ attacker who breaks in can see it too $\Leftrightarrow$ you are trusting your validator operator $\Leftrightarrow$ weak privacy
  • Suggesting that validators/operators can encrypt balances under their own keys is no better, since the operator still holds the key
  • Suggesting that trusted hardware can make it better is tenuous (see Arc discussion on attacks)
• Bad: Amounts and balances are only encrypted “in flight” between full nodes / validators $\Rightarrow$ high trust assumption on these intermediaries
• Good: Easier to do key management
  • Banks/customers should like this
• Good: Easier to implement more complex auditing policies, precisely because validators see everything / the privacy guarantees are weaker
  • Banks/customers should also like this

Claude’s take

Aptos confidential assets encrypt balances on the public ledger under keys the user owns, so secrecy is a cryptographic guarantee: only the key holder can read amounts, and no operator can.

Canton keeps balances in plaintext in each participant node’s local database and gets secrecy from routing — the protocol simply never sends the data to non-stakeholders, with inter-node encryption under node keys covering transport only.

So the trust anchor differs:

• Aptos trusts math and the user’s ability to protect their decryption keys.
• Canton trusts your hosting participant operator, plus whatever leaks through divulgence, timing, and workflow metadata.

Arc²

• Bad: Leverages trusted hardware to encrypt blockchain state on validators under a master secret key (MSK)
  • Unfortunately, trusted hardware is much easier to break in practice than in theory
  • It has been fully (and partially) broken several times in the past. See just a few recent attacks:
    • batteringram.eu/batteringram.pdf: “arbitrary plaintext read/write access and extracting SGX’s platform provisioning key, thereby dismantling trust in remote attestation”
    • tee.fail/files/paper.pdf: “extract secret key material (such as attestation keys in some cases) from machines in fully trusted status”
    • wiretap.fail/files/wiretap.pdf: “extract an SGX attestation key from a machine in fully trusted status” $\Rightarrow$ “end-to-end attacks on both confidentiality and integrity guarantees of deployments with multi-million dollar market caps, allowing attackers to disclose confidential transactions or illegitimately obtain transaction rewards”
• Bad: Uses a secret-shared MSK on validators (or, more loosely, their operators)
  • $\Rightarrow$ subject to collusion attacks by validators $\Rightarrow$ the MSK could be revealed $\Rightarrow$ privacy guarantees would be broken without even having to break the trusted hardware
  • The typical counterargument here is that “more trusted hardware on each validator’s KMS will fix this.”
    • But will it ¯\_(ツ)_/¯? (See attacks above!)
• Good: Supports arbitrary privacy-preserving* computations, beyond just payments
  • *Of course, under the big caveat of relying on (repeatedly-broken-into) trusted hardware.
• Good: Easy key management
• Good: Very flexible auditing

But $\exists$ secure trusted hardware!

One reasonable objection to “trusted hardware keeps being broken into” is that such Intel SGX attacks will not transfer to other trusted hardware platforms.

I doubt it³$^,$⁴$^,$⁵$^,$⁶.

Although there are ways to reduce the attack surface of trusted hardware (e.g., see Sanctum⁷ from my group at MIT back in the day), in practice, they tend to come with lower performance and/or less functionality. And it so happens that trusted hardware companies mainly compete on performance, functionality and (I hope) developer-friendliness. They hardly compete on security, because it’s hard to: there’s always someone else who can (mis)claim more security. And such claims are hard to adjudicate by the market.

Thus, what ends up happening is a race to the bottom, sacrificing security for extra performance and functionality.

Claude’s take

Aptos protects balances with pure cryptography: ciphertexts sit on-chain under the user’s own key, so an attacker who compromises every validator still learns nothing about anyone’s balance.

Arc protects balances with a master secret key (MSK) housed inside trusted hardware on the validators. This gives Arc two failure modes Aptos doesn’t have: (1) hardware-level attacks that extract the MSK from the enclave, which were demonstrated repeatedly in practice (see links above), and (2) validator collusion that reconstructs the secret-shared MSK without touching the hardware at all.

The trade-off is expressivity: Arc’s enclaves can run arbitrary confidential computation, not just payments, while Aptos’s on-chain approach is limited to payments. But that expressivity assumes trusted hardware won’t get broken into. So you’re trading a mathematical guarantee for a physical one, and the physical one has a poor track record.

If I had to pick between Canton and Arc, I’d pick Arc due to its simpler design, clearer trust model (IMHO), and higher expressivity.

References

For cited works, see below 👇👇