sinu

| sinu.eth
| tech lead @ neutral systems maxi

[sinu @sinu_eth]

This year I will try to communicate more. Here is what motivates me to work on @tlsnotary, which I consider to be working on @ethereum, and why I think it continues to be the best use of my time.

you may now pass go

https://t.co/mtDOmnTjGW

[sinu @sinu_eth]

@nico_mnbl @0xSachinK What depends on setting?

Using "zk" or "proof" to describe TEEs is pretty misleading. They give publicly verifiable signatures!

[sinu @sinu_eth]

TEEs are strictly worse from a privacy perspective. The user's credentials and all queried API data are being processed by an unobservable remote machine.

That being said, I agree the UX/DX and fragility of selective disclosure using zkTLS + ZKPs is also an issue. It needs to get better so there is no trade off.

[sinu @sinu_eth]

My thoughts:

Peer offers low friction exchange between uninteroperable financial ledgers, that is a great product. A product worth being excited about.

TEEs offer strong integrity and censorship resistance with or without zkTLS. They also ostensibly provide confidentiality, but that is practically unfalsifiable.

A TEE is a computer sitting in a data center somewhere far away from a user, which a vendor (e.g. Intel) promises they:

1) put a lot of work into making the physical hardware difficult to compromise
2) securely manage a master key which is only ever used to attest to keys burned into their TEEs

When a user sends private information to this remote machine, they are trusting (after hopefully actually verifying the TEE's certificate) the integrity of a long chain of claims which they can not verify. These kinds of trust chains offer an easy target for sufficiently motivated adversaries, including (lawfully administered) state surveillance. One could argue that to be true even about ones own machine and the software running on it, which is true to an extent but that is a sort of trust nihilism which I don't accept. Observability and locality matters. Hopefully local AI will help here.

But, if an approach which minimizes the trust unpinning user privacy also imposes significant cost on the user and the developers, it is hard to justify finger wagging. It first and foremost must be a scalable product. This is the classic dilemma with all privacy tech. Peer meaningfully offers user sovereignty, right now, and people are using it. They have determined (rightly or wrongly) the friction imposed by using zkTLS is a material hindrance to scaling the product, i.e. offering financial freedom to more people.

Yes, this is the pragmatist argument that CROPS builders dread. The solution is to ruthlessly drive the friction imposed by CROPS software to 0 so there is no trade-off.

The TLS transcript commitment problem is solved. MPC-TLS offers reasonable performance suitable for high-stake applications, and proxy commitment offers TEE-level performance with a marginal integrity assumption for the verifier. The friction frontier is in selective disclosure: we need a fast client-side zkVM which is easily programmable using general purpose programming languages. Performance and programmability. That's why we're building SpeakUp https://t.co/2tSovmRNrJ

[Peer (Prev. ZKP2P) @peerxyz]

Peer is now running on TEEs.

Payment verification just got 100x faster, from ~30s to <300ms.

Here's what changed.

[trent.eth @trent_vanepps]

https://t.co/GajUKQC8li

[sinu @sinu_eth]

Interesting! https://t.co/hIgiBfeWCf

[sinu @sinu_eth]

@hackerdocc @tlsnotary Very roughly speaking, SpeakUp uses VOLE ZK which size + time scales linearly with small constants. Ligero size is sublinear and time superlinear with larger constants.

[sinu @sinu_eth]

@pratiks_crypto @tlsnotary Yes!

[sinu @sinu_eth]

@sug0x0 @PrivacyEthereum VOLEith has higher prover cost and larger proofs because it can't use LPN-based VOLE generation.

SpeakUp is targeting the designated verifier setting, and interaction is not an issue

[TLSNotary @tlsnotary]

SpeakUp is built for exactly the setting TLSNotary operates in: a low-power device running the prover, online with a designated verifier. A fast client-side zkVM is the missing piece for scaling web proofs.

[PSE @PrivacyEthereum]

SpeakUp: a new zkVM we're prototyping for private, client-side proving of WebAssembly programs - built to run on low power devices such as mobile phones and browsers.

The underlying proof system explore different tradeoffs for different use cases from mainstream zkVMs. SpeakUp is interactive, and uses vector oblivious linear evaluation (VOLE), which provides a fast linear-time prover and post-quantum security at the cost of larger proofs.

See the early design draft below, we're looking for public feedback 👇
https://t.co/udhRQ1hD1R

[TLSNotary @tlsnotary]

Who's your #1 Spotify artist?
Prove it onchain. We pay the gas.

[sinu @sinu_eth]

@thefrozenfire @ViktorBunin thought this was a runeword

[trent.eth @trent_vanepps]

as of last friday, I no longer work at the EF

nothing but respect for the brilliant people i worked with over the last 5 years on network upgrades + funding efforts

I intend to continue working on @ProtocolGuild and Ethereum political economy as long as funding is available

[sinu @sinu_eth]

@colludingnode the question is "does this need to be publicly verifiable?". The answer is almost always no.

Money and identity covers most of it

[Leo Alt @leonardoalt]

Here are my @eth_proofs Beast mode slides: https://t.co/fz0DUtoszv

tl;dr ZK WebAssembly gud, about to be even faster

[sinu @sinu_eth]

I already pledged to CROPS in January
https://t.co/GJQ4CGTfyX

[Leo Alt @leonardoalt]

I've been saying this: WASM + custom ISA is how we employ compilers to make general purpose zkVMs even faster. Now we can prove it.

[vitalik.eth @VitalikButerin]

I was recently at Real World Crypto (that's crypto as in cryptography) and the associated side events, and one thing that struck me was that it was a clarifying experience in terms of understanding *what blockchains are for*.

We blockchain people (myself included) often have a tendency to start off from the perspective that we are Ethereum, and therefore we need to go around and find use cases for Ethereum - and generate arguments for why sticking Ethereum into all kinds of places is beneficial.

But recently I have been thinking from a different perspective. For a moment, let us forget that we are "the Ethereum community". Rather, we are maintainers of the Ethereum tool, and members of the {CROPS (censorship-resistant, open-source, private, secure) tech | sanctuary tech | non-corposlop tech | d/acc | ...} community. Going in with zero attachment to Ethereum specifically, and entering a context (like RWC) where there are people with in-principle aligned values but no blockchain baggage, can we re-derive from zero in what places Ethereum adds the most value?

From attending the events, the first answer that comes up is actually not what you think. It's not smart contracts, it's not even payments. It's what cryptographers call a "public bulletin board".

See, lots of cryptographic protocols - including secure online voting, secure software and website version control, certificate revocation... - all require some publicly writable and readable place where people can post blobs of data. This does not require any computation functionality. In fact, it does not directly require money - though it does _indirectly_ require money, because if you want permissionless anti-spam it has to be economic. The only thing it _fundamentally_ requires is data availability.

And it just so happened that Ethereum recently did an upgrade (PeerDAS) to increase the amount of data availability it provides by 2.3x, with a path to going another 10-100x higher!

Next, payments. Many protocols require payments for many reasons. Some things need to be charged for to reduce spam. Other things because they are services provided by someone who expends resources and needs to be compensated. If you want a permissionless API that does not get spammed to death, you need payments. And Ethereum + ZK payment channels (eg. https://t.co/1Q2Hqg0DZg ) is one of the best payment systems for APIs you can come up with.

If you are making a private and secure application (eg. a messenger, or many other things), and you do not want to let people to spam the system by creating a million accounts and then uploading a gigabyte-sized video on each one, you need sybil resistance, and if you care about security and privacy, you really should care about permissionless participation (ie. don't have mandatory phone number dependency). ETH payment as anti-sybil tool is a natural backstop in such use cases.

Finally, smart contracts. One major use case is _security deposits_: ETH put into lockboxes that provably get destroyed if a proof is submitted that the owner violated some protocol rule. Another is actually implementing things like ZK payment channels. A third is making it easy to have pointers to "digital objects" that represent some socially defined external entity (not necessarily an RWA!), and for those pointers to interact with each other.

*Technically*, for every use case other than use cases handling ETH itself, the smart contracts are "just a convenience": you could just use the chain as a bulletin board, and use ZK-SNARKs to provide the results of any computations over it. But in practice, standardizing such things is hard, and you get the most interoperability if you just take the same mechanism that enables programs to control ETH, and let other digital objects use it too.

And from here, we start getting into a huge number of potential applications, including all of the things happening in defi.

---

So yes, Ethereum has a lot of value, that you can see from first principles if you take a step back and see it purely as a technical tool: global shared memory.

I suspect that a big bottleneck to seeing more of this kind of usage is that the world has not yet updated to the fact that we are no longer in 2020-22, fees are now extremely low, and we have a much stronger scaling roadmap to make sure that they will continue to stay low, even if much higher levels of usage return. Infrastructure for not exposing fee volatility to users is much more mature (eg. one way to do this for many use cases is to just operate a blob publisher).

Ethereum blobs as a bulletin board, ETH as an asset and universal-backup means of payment, and Ethereum smart contracts as a shared programming layer, all make total sense as part of a decentralized, private and secure open source software stack. But we should continue to improve the Ethereum protocol and infrastructure so that it's actually effective in all of these situations.

[sinu @sinu_eth]

@thefrozenfire https://t.co/YmaS9nVelB

[Alexey Grigorev @Al_Grigor]

Claude Code wiped our production database with a Terraform command.

It took down the DataTalksClub course platform and 2.5 years of submissions: homework, projects, and leaderboards.

Automated snapshots were gone too.

In the newsletter, I wrote the full timeline + what I changed so this doesn't happen again.

If you use Terraform (or let agents touch infra), this is a good story for you to read.

https://t.co/Mbi3oM4HMn