Content
@
0 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
The "onchain" narrative is a bit weird to me because it's like flexing about being "onAWS" or "oncloud" A chain is only one part of your tech stack. In fact, having to compose everything onchain is an anti-pattern that emerged because light client support sucks Offchain is more expressive, safe, and cost efficient
23 replies
3 recasts
112 reactions
Henri Stern Ꙫ
@henri
💯 I quite like the term but agree with a lot of this Never picked a product because it's NoSQL, personally
1 reply
0 recast
3 reactions
androidsixteen
@androidsixteen.eth
And you avoided many tears and sleepless nights as a result Maybe that's one commonality between "onMongo" and "onchain" — it signals that you're a masochist 😆
1 reply
0 recast
2 reactions
Henri Stern Ꙫ
@henri
dark 😆 -- there is the fact that onchain implies deeper user implications (since self custody and interop are the benefits) than a db choice -- so it feels like more of a difference in kind than (eg) lower latency. Part of what's interesting in our work (at Privy): it's developer tooling but very user centric
1 reply
0 recast
1 reaction
androidsixteen
@androidsixteen.eth
Self custody (or PKI) is off chain :) And interop is unfortunately onchain because we lack trust-minimized IO with offchain coprocessors. I hope that next gen infra focuses on light clients for reads and fast proof generation/verification for writes The root of trust (the chain) should have less app code IMO
3 replies
0 recast
2 reactions
androidsixteen
@androidsixteen.eth
Sidebar, this is also why I fw EigenLayer Better way to express logic while still inheriting economic security from the chain It breaks the mental model of encoding logic in contracts as the prevailing paradigm
0 reply
0 recast
1 reaction
