Content
@
https://warpcast.com/~/channel/m3ter-heads
0 reply
0 recast
0 reaction
I. Christwin〔▸‿◂〕💡
@ichristwin.eth
A while back, @anoncast shared some links that showed data that is missing from /arweave's permanent data storage. This quickly sparked a debate as to whether the user data was dropped from storage by the network or whether it was ever published in the first place. All that reminded me of this talk from @devcon 3 that discussed some of the challenges of attributing fault for data unavailability in Ethereum plasma. How do you prove who is at fault in such a situation? https://youtube.com/clip/UgkxWQbMED4cuTcam6PqDr0VOvGyQCB5wz7S It's just best not to make room for such situations at all, because it is going to be a nightmare to build security on such assumptions. What does this mean for /ao? 🤔...and what does this mean for my work on the m3tering protocol that leverages the guarantees of Arweave?
1 reply
1 recast
4 reactions
I. Christwin〔▸‿◂〕💡
@ichristwin.eth
Building DePIN entirely onchain doesn't seem practical in the foreseeable future and I came to the conclusion these networks would either need to implement their own consensus mechanisms, or instead use data availability to ensure that every happening offchain remains secure. https://warpcast.com/ichristwin.eth/0xf885c1f6 My implementation follows the later and uses Arweave to ensure that anyone is always able to verify for themselves the correctness of computation happening offchain on any smart meter, without needing to know the state of every single device using the protocol. But what happens when you are unable to find the data you need for said verification? ...is anything still valid? ...when did it stop being valid? It's plasma all over again. Rollups fixs this. Every DePIN would rediscover the rollup architecture, when security starts to matter. Honestly the more I build in this space, the more I come to appreciate ethresear.ch and I aspire to contribute to the work it's doing for this industry
1 reply
0 recast
4 reactions
