Coming from a POA Blockchain ((bloxberg.org = EVM chain with small number of trusted nodes) and eventually ETH2 sharding situation) I would love to understand more how moving to a HoloChain App would help! The specific applications are basic income and mutual credit.
1 Like
Hi @wor! So there are different things here, and I’m sure I won’t address everything, so happy to continue the conversation later on. Also I’m not at all an expert on POA blockchains, so things I’ll say here that apply to blockchain architecture more generally may not apply to POA ones.
So maybe I’ll start with some core concepts, and then get to the benefits in mutual-credit per se?
- In holochain, every app (DNA) creates its own DHT network. The ID of the network is the hash of the code plus some properties, so basically everyone that has the application installed and is playing the game has agreed beforehand to the rules of the game. You can think of this as having consensus about the rules before starting to play, but there is no consensus about the state, as the DHT is eventually consistent.
- The rules of the game are deterministic functions that return, for each type of data, whether that piece of data (entry) is valid or not. Since all players have agreed to the same rules, validating the same entry has to produce the same result, regardless of who runs it and when. Thus, the validators are chosen basically random, when the agent creating the entry tries to publish it into the DHT.
- One important kind of rules is who is allowed to enter the game itself. You can do things like “only the agents approved by this authority can enter”, “agents have to be invited in by some other agent that is already inside the network”, etc.
Benefits for mutual-credit apps:
- Potential for improved privacy: you can define community currencies DNAs in which by some mechanism only the participants can enter, so external participants won’t be able to see any data for that app.
- Much less cost: if the app is run on the local devices of the agents, then the cost of running it is basically the CPU processing energy cost of the computation, plus some overhead in synchronizing with the DHT. You can also use hosted apps (DNAs that run in holoports for example), for which the app provider has to pay, not the actual user -> huge UX improvement over blockchains. Also, the amount to pay will be orders of magnitude lower because there is no expensive consensus mechanism going on.
- Scalability improvements: the more agents that have the app installed, the more resources the network has. So, in practice, the processing power (or in the case of mutual-credit we could think of network wide TPS) is increasing linearly with the number of nodes, while the cost for each node is maintained constant.
- Possibility of local networks: if internet access is difficult, a holochain DHT can run on local or community devices alone, allowing flexibility there.
- Straightforward interoperability: exchanging two currencies will be as easy as doing a transaction in one DNA and the reverse in the other DNA. Also, you can benefit from other service like DNAs that will grow in the ecosystem.
- With one mutual-credit DNA, you can bootstrap a myriad of community currency networks, just by changing some properties.
- Finality improvements: you don’t have to wait for blocks to be confirmed, if you are a good actor and the validation rules are deterministic you can basically be confident at the moment that the transaction is finalized. (Caveat: this depends on your strategy to prevent sybil attacks, but I don’t see that as a much of a problem in the type of networks you are describing).
- Improved resilience: you don’t have to rely on the central validators. If there are at least some nodes running, you the application is running as well and they can act as validators.
Also, you may encounter some friction by moving to holochain, meaning, some things are a bit harder to do on holochain than with other architectures:
- Changing the rules of the game implies creating a new game: you cannot force anyone to upgrade, and the upgrade mechanism has yet to be defined but in principle shouldn’t introduce much friction.
- You can tweak parameters inside the network (for example, the demurrage rate) but you have to be careful to maintain the determinism of the rules of the game. So you need good solid design to maintain data integrity.
- You may be in trouble in veery small networks, if the nodes are coming on and off all the time. If I publish something to the DHT but I’m the only one running the app, it won’t get published to any other agent and if I turn off my PC the new pieces of data won’t be accessible to another agent turning on their app.
Let me know if you want more clarity on any of these, I also welcome any challenges to the points I’m making.
5 Likes
Thanks for this! All my next questions are more about a specific case. Which I’ll post more here https://forum.holochain.org/t/basic-income-community-currency-migration-from-blockchain-to-holochain
Would this get resolved with a Holoport and Holo? If not, what is kind of a minimal viable network size?
Thanks!
fantastic information @guillemcordoba ; thanks for this!
Yes, I should think so – I can imagine Holo offering a “pay-for-resilience” service for otherwise fully P2P apps, where a few HoloPorts commit to keeping your DHT in existence as the real participants come and go. That said, it shouldn’t be too hard – especially in a business setting – to provision some always-on nodes who don’t actually participate but simply replicate the whole DHT. Just install the runtime on a back-office server, install the app, and away you go.
Awesome, thanks for the clarification. Excited to follow the development and join in when able!
Question, when you change the rules of the game does it create a new set of data chains too?
So would users loose all their data entries for that game and need to start over, or does it use the same data store, just with a new logic network?
Yeap, each cell (dna-agent pair) maintains its own source chain. I think this explanation is what you are looking for: Concepts: Dna and Zomes: Holochain Gym
Hmmm, so to upgrade an app, you need to trust the app creator to migrate data over as a single source of failure, or start over?
Are there data migration alternatives?
I think the built-in upgrade mechanism will behave more like each agent that upgrades brings with them the necessary data that is still relevant to the upgraded dna.
But fundamentally, you can’t force agents to move from one dna to another. So as long as the old dna has agents which choose to keep playing the game, that dna will still exist.
1 Like