Hi! this is my first post on the forum, though I’ve been reading about Ceptr & Holochain for a few months now, very interesting stuff. Agent-centricity seems like a powerful approach to distributed application development, and very aligned with local-first computing. I dove into Holochain when I realized how far removed blockchain is from the principles of decentralization we see in nature and human interaction, using very cumbersome mechanisms to enforce unnecessary global consensus (logical centralization).
I have a good grasp of how normal DHT’s work, but I’m having a bit of trouble understanding the incentive structure around validation in the holochain architecture. Could agents just choose not to play the role of an authority when called upon to validate another agent’s entry? Does the expectation that peers will perform validation depend on goodwill or some kind of social contract, or is the duty of validation baked in at a deeper technical level?
Someone may correct me if I’m wrong, but I believe it is baked in as a prerequisite for participating in a Holochain application that you will contribute to validation.
Note that because of the high efficiency of Holochain, the computational load required for validation is small enough that you don’t need to create any extra incentive. The incentive is you get to participate in the hApp, basically.
Thanks! Would you know if there’s any “checking” for that requirement?
Wondering how it plays out considering each node is supposed to be able to go offline at any point, so some nodes which are less active could have performed less validation.
I guess along similar lines, I’m wondering if there’s a “check” for storing other nodes’ data as well. The resilient DHT requires nodes to store data for an address neighborhood, but is this contribution something that can be checked to reduce free-riding?
To give a proper answer, there are a some layers to it.
Technically, people CAN freeload – rrDHT allows for the possibility of marking your span of coverage of the DHT is ZERO. This basically means you host only your own address and your source chain. Holo hosted users will be configured this way because of the difficulties of getting their signature from their web browser even to sign network communications with them.
In an idealized world we can say “Everybody should carry their fair share,” but if we want Holochain apps to work in the real world, we need Holochain and rrDHT need to provide for real world constraints. What if your node is on an IoT device and doesn’t have enough storage? What if you’re on a mobile phone with expensive bandwidth? The idea is that your Holochain conductor “knows” about these constraints and can set your rrDHT spans accordingly. Also, when you first join a DHT, you haven’t yet synchronized all the data you’re supposed to hold, specifying your span of coverage allows for joining with no data, then syncing some, expanding the span you can say your holding, then syncing some more, and so on.
Since you can set your span of DHT coverage that you serve to zero, it creates little incentive to misrepresent what you hold. However, as more layers of validation come online there also comes the ability to detect if nodes are misrepresenting their coverage (failing to serve hashes they say their holding) or serving incorrect/incomplete meta-data (like links, headers, or updates).
If you want your app to enforce a more idealized approach to load sharing, you’ll have to put your own incentives in place for doing so.
In general, we think the best way to have people play nice is to have smart defaults so that it’s actually harder to not cooperate well than to cooperate well. And as long as we can keep the workload light and well divided amongst participants, then there’s no reason to go to bother of hacking your node to not cooperate.
I’ll be building a precedent which involves massive degrees of machine learning processing and curation of data which is collected in an IoT network. Obviously this bandwidth and CPU cycles will be somewhat decoupled from the mobile phone clients, so there are planned economic incentives to host DNAs on massive desktop machines (i.e. for processing models, and expensive backend rendering processes using Blender)
I’ll report here as it comes along.
If anybody else has a similar prior precedent that involves strong asymmetry between hosts and clients please post them here! With links! … i.e. as opposed to the usual symmetric holo use case where all clients are equivalently hosts in roughly equal proportion.
