alt Hacker NewsIt feels like the state merging approach just pushes the hard problems onto the user, without giving them the tools to solve those problems properly.
Imagine an application where an authorized group of users can create and vote in polls, using cryptographic signatures and public/private keys for user verification.
What prevents me from connecting and saying that "everybody's state is wrong, that poll in 2024 which didn't reach quorum actually did, because I voted in it, here's my vote." How can the state merger know that the existing state has been valid for two years, and that the vote shouldn't be retroactively applied?
Blockchains solve this by having state get more authoritative as blocks age. To undo the `poll_didnt_reach_quorum` state transition from 2024, one would have to rewind all blocks that have been created since, and PoW / PoS ensures that this is incredibly costly to do.
On a related note, how does your design prevent sybil attacks, where one participant floods the network with many large contracts and large state updates?
Appreciate the feedback.
> It feels like the state merging approach just pushes the hard problems onto the user, without giving them the tools to solve those problems properly.
We've created many of these tools, and have used them to implement practical applications like group chat, a CMS, and a social network, and we and others will build many more tools over time. Designing applications for Freenet can require some creative problem solving, but each problem only needs to be solved once.
> What prevents me from connecting and saying that "everybody's state is wrong, that poll in 2024 which didn't reach quorum actually did, because I voted in it, here's my vote." How can the state merger know that the existing state has been valid for two years, and that the vote shouldn't be retroactively applied?
You could solve this similarly to Bitcoin by having a mechanism that "locks" poll results at a particular point in time to prevent subsequent additions, analogous to how mining repeatedly locks in the blockchain.
> On a related note, how does your design prevent sybil attacks, where one participant floods the network with many large contracts and large state updates?
Peers in the network track cost/benefit of each connected peer, so if a peer starts to consume a lot more resources than it provides then its neighbors will disconnect, a kind of immune response.
I'm sure that once the network is big enough to attract large-scale attacks we'll need to adapt our approach, but I think we have a solid starting point.